It certainly has, using them on Visual Studio 2022 C++20 mode, and you don't need D's hack to import them inside functions.
So visual studio has an implementation not many people use, what of the other compilers? I'm still yet to even compile a project that actually uses them, and they must have spent a significant proportion of my entire life trying to get them in the standard.
Naturally not every compiler is yet fully C++20 compliant but they will get there, VC++ is there, next release of GCC is looking quite good, clang well lots of issues anyway now that Apple and Google resources went away and not everyone has the same love for upstream.
As for the hack, go dive into D forums from like five years ago thereabouts, since import statements in D fully parse the source of the respective modules, the hack to speed compilation time was to move import statements into the function bodies so that they are only processed if that code is actually parsed.
If I am not mistaken, Andrei was one of the persons suggesting this.
That is a damp squib, of all the things I view as hacky in D that is not one of them.
Local imports are favoured for stylistic reasons anyway, they don't actually make all that much difference for code that isn't dead anyway. What's wrong with importing things where they are used?
IIRC Andrei proposed the local imports, but it was only a matter of removing an error message because they were banned at the time.
As for what is wrong with local imports, it makes impossible to track down module dependencies unless one goes grepping for imports all over the place.
Nobody is making anyone use them. It's a personal preference.
As for "impossible", `import` is a keyword, so it's trivial to find them all using, yes, grep. D was designed to be more greppable than C/C++. For example, it's really hard to find all the cast expressions in C, but since `cast` is a keyword, it's trivial in D.
(Cast expressions are all potential bugs, so being able to find them all in a code review is a good thing.)
> five years ago
Is an eternity in the software business.
In those 5 years, D's competition reduced even further the need to actually bother with D, slowly taking away all features that made D special.
If it were a hack, people would only do it for it's hacky-ness rather than as a style preference. The former is simply not true in industrial usage of D. In less words: It's bullshit.
What industrial usage?
A couple of companies that still haven't yet left the community, because each year something new is going to be the Thing to bring everyone into D?
Lets see how D manages to survive when the core team is no longer calling the shots.
What languages don't have something new added on a regular basis? Yes, we improve D consistently and regularly.
The location of an import has nothing to do with compilation speed. The only time it would ever make a thing compile faster is if 1) it is local inside a template function, 2) that template is never actually used, AND 3) the module is never imported anywhere else in the program.
That does happen - I use this pattern for optional dependencies which aren't even looked at if not actually used - but it isn't generally the case. You have to actively think about it to fulfill all three requirements.