> why would it matter ? AFAIK D doesn't even have an ISO standard.

Sure it does.

D is defined by the DMD compiler as the reference implementation.

Whatever DMD allows for minus implementation bugs, is what the D programming language means.

C++ is defined by an ISO standard, a document that specifies what every implementation is required to implement.

So any D developer can be sure their code is compliant as long as DMD accepts it, while a C++ developer needs to pay attention how close their favorite compiler is to ISO C++.

> you at least get whole-program safety for libc calls since it works by replacing such calls through dynamic loading

Libc is a very tiny portion of any industrial grade C++ application, and only relevant in open source systems, as it is shipped in binary form in other platforms.

> any D developer can be sure their code is compliant as long as DMD accepts it, while a C++ developer needs to pay attention how close their favorite compiler is to ISO C++.

That's a cute, but if that's "the letter of the law" then Walter can replace DMD with emacs in the next release and it'd still be a conforming implementation, and you'd just have to rewrite your codebase in lisp to keep it functioning. All the options available to the D programmer in that case (like "keep using the previous version") are also open to C++ programmers when their compiler makes a change that breaks their code.

In practice everyone cares about stability. The C++ standard provides a signal that "this behaviour is (not) likely to change in the next release". All other features not mentioned in the standard like compiler flags and implementation details like the stack and the heap are on par with features in D when it comes to compatibility from version to version.

The C++ programmer who writes "to the implementation," not "to the standard" is in at least as stable and predictable a situation as the comparable D programmer.

>That's a cute, but if that's "the letter of the law" then Walter can replace DMD with emacs in the next release and it'd still be a conforming implementation, and you'd just have to rewrite your codebase in lisp to keep it functioning.

Which is a contrived argument

It is, and I said so too -- I was responding to some nonsensical lawyerism by showing that it was ridiculous on its own terms, and then I spent the rest of the post (the bulk of the post) talking about actual effective, pragmatic ramifications of having a language standard.

Well, you don't need a standard that much if there's a single compiler, isn't that true?

Sure, I agree with that. I think it's a coordination mechanism, and it tends to make language progress more conservative. I don't know if/when it's a net win, and I certainly wouldn't expect (or want) D or Python or Ruby to do it -- I think they do a better job of managing their own growth and development.

I do think it's a bit crazy to say that it can increase uncertainty about future compatibility, though -- on that front I think it standardisation has a strictly stabilising effect.