Hacker News Reader

Comment by pjmlp | Hacker News Reader

It is on the standard, update yourself.

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.

View on HN

I'm aware it's in the standard now, my point is that it's taken them a very long time to get to this state and what they do have isn't all that impressive. Concepts have possibly taken my actual whole life although I don't know when the first proposal was.

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.

No matter how long C++ takes to adopt something, the language at least knows what it wants to be, and has an ecosystem to keep it going for decades that will outlive us.

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.

> 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.)

You call that a hack? The reason for it was "locality", i.e. it makes it clear what dependencies a function has. Compiling faster was just a side effect.

> five years ago

Is an eternity in the software business.

It is an hack, given that other languages don't need such "solutions".

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.

Meanwhile D still exists and has all those features.

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.

The features alone are useless without an ecosystem.

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.

> something new

What languages don't have something new added on a regular basis? Yes, we improve D consistently and regularly.

> Compiling faster was just a side effect.

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.

Reply on news.ycombinator.com