[kazinator]

That's true when you have one implementation of something, and you're lucky enough to have a document that is so detailed that it counts as a specification.

The specification of an ISO-standard language is the main contract, taken seriously by implementors. In areas where implementations happen to conflict with it, you will find that over time they give way to the specification. Implementors add their own bits to their local version of the specification. Beyond that are undocumented behaviors.

Neither the specification nor implementations give way to wishful thinking on the part of the programmers.

[doctor_eval]

The only thing that matters is the implementation of the system you’re communicating with or using.

With any luck, their interpretation of the specification will be similar enough to yours that you can communicate.

The only wishful thinking in such cases is that the implementation will perfectly implement your interpretation of the spec. The code you’re calling isn’t going to magically conform to your interpretation just because it says it’s conformant.

This is why we have interop testing and even interop conferences. Specs almost always have subtle ambiguities and missing details which implementers need to fill in themselves.

[kazinator]

Why would we have interop conferences, when the only thing that matters is the implementation of the system you're using?

[doctor_eval]

The comment I'm ultimately replying to is this:

> In computing, the specification is the gold standard, followed by documented, committed implementation behaviors

my point is that a specification is not the gold standard, because it can be interpreted differently by different readers.

We need interop conferences to help identify the places where the specification is insufficient to fully and unambiguously describe the desired behaviours.

This can only happen because of input from implementors. And since the specifications are always evolving, they are always going to trail the implementations.

[tialaramex]

It's true that Mother Nature doesn't care about your wishful thinking, but she also has no time for your paperwork.

There's a rough notion of the C++ programming language, and the ISO document is a description written by some humans which resembles it closely enough that you know they weren't describing something else. The people implementing the three major compilers for C++ don't really care about the ISO document†, but the meetings to agree the document serve to also agree changes they should make to their implementations, to a lesser or greater extent.

† ISO/IEC 14882:2020 is the current standard. Yes you read that correctly, that's C++ 20. No that's not the "current" C++ language, an ISO document for C++ 23 will be published probably later in summer 2024. Nobody cares. GCC volunteers working on their compiler don't care obviously. Microsoft employees paid a substantial amount of money specifically to work on MSVC as their day job don't care. Nobody cares, the ISO document is purely an exercise in vanity. If you try really hard to buy the "official" ISO publication as an actual paper document, most likely after months of struggle you'll get... an apology and a link to the sprawling PDF for your money.

[staunton]

You absolutely can buy the ISO publication (though I wouldn't recommend it). Also, given that n new version of the C++ standard is published roughly every three years (and named every three years), I'm not really sure what your point is.

Implementors will (mostly) implement the new standards in due time and it actually does matter what the standards say. So what is it that nobody cares about here?

[tialaramex]

You can buy the PDF. If you're under the impression you can buy the paper document you're most likely just looking at some Print On Demand automation and, if you gave them the money their actual POD backend would look at the PDF and say error, that's not a document I can actually make [it would be about 2000 printed pages] - hence as I said you'll get an apology and a PDF link.

Nobody cares about this document. The implementers do not, in fact, go back and change their implementation to match mistakes in the document, they might eventually fix the document instead, but honestly it just doesn't matter. Given the work expended to write this document that's very stupid, but it's not my fault, if it were up to me obviously they wouldn't do it. The implementers do care about consistency, and so there are cases where they resolve an inconsistency by comparing against the document, but these aren't common and if the general feeling is that the document is wrong, well, it's wrong. They're just words, if you can be bothered you fix the document, you don't pretend that somehow it's sacred and your compiler should be altered to match the error.

On most of the difficult questions, the document just quietly avoids answering. In a huge document you can easily just assume there's an answer somewhere else, unless you knew there isn't. Maybe the ISO document explains how provenance works somewhere right? No? No. That's tricky, there are powerful forces who want different things, much easier to just not say anything.

The authors themselves concede that they're not really very careful with the language, did they write "can" for a normative declaration here even though the document insists it will use "should" not "can" when it is making normative declarations ? Well, too bad, I guess somebody wasn't careful enough when editing that part. Nobody is going to re-issue the document, if you make it your life's work for a year or two you can probably fix it, but you will be met by exasperated sighs everywhere. Nobody cares. You are trying to make them care, they will resent you.