On 05/11/2025 04:04, Tom Honermann via Std-Proposals wrote:
>
> The above indicates to me a possible reason for the disconnect that is
> apparent between yourself and the several people on this list that have
> pushed back against your implementation based specification approaches.
>
> Implementers do not necessarily read the paper. Current implementers
> very likely will. But the standard doesn't exist for just the current
> implementers. Future implementers will implement the standard based on
> the words in the standard. Over time, the standard will change, but your
> paper will not. An implementation written in 2025 is not necessarily
> relevant in 2035. The standard must stand on its own.
>
> Tom.

I am not particularly interested in this particular issue of
relocatability, but it's possible that I can give other reasons why
"specification by implementation" is a bad idea as a general principle.
(Obviously most people here already know that proper specifications are
important - I am merely hoping that I can help Frederick understand the
point better. Perhaps then he can apply his enthusiasm and energy with
a more constructive focus. And I am writing this as someone who has not
written any C++ standards proposals - I'm just an interested user.)

Implementations almost invariably add more detail than you need for a
specification. For example, it is totally irrelevant to the working of
the proposed relocatability system whether the constants are of type
"int", or any other integer type. (I cannot comprehend why the paper
author doesn't use an enumeration class, but that's another matter.)
However, if the feature is defined by the implementation, and the
implementation uses "int", then it is fixed at "int". Sooner or later,
someone will rely on that (Hyrum's law). On a 64-bit system, it's
likely that a 64-bit type would be more efficient - on an 8-bit target,
an 8-bit type would do the job better. But because of the overly
detailed implementation, rather than a clear specification, we'd be
stuck with "int" despite all its disadvantages.

Secondly, when there is only an implementation and not a specification,
it pushes toolchain vendors to follow that implementation. That limits
their freedom to do better. If the "std::countl_zero" function in C++20
had been specified by an implementation, library writers would be stuck
with that - instead of implementing it with __builtin_clz(), or inline
assembly, or other compiler magic, or however they choose to do it.

Thirdly, forcing implementations is crippling for the future - such as
when new relocatability types are added or unnecessary ones removed, or
pattern matching makes "else if constexpr" trees obsolete.

Sometimes it can be helpful to have an example possible implementation -
in the main text if it is very short and simple, or in an appendix if it
is more advanced. But it should never be the defining explanation of
the feature. And it should not be there at all if it is obvious how to
implement the feature.

Software development always starts from a specification, and moves
towards executable code. You don't start with some random text, fiddle
with it until the compiler accepts it, and then try to figure out what
it does. You start with a purpose, a description of what you want.
Sometimes that is no more than an idea in your head, but the more
important the code, and the more people who will see it and use it, the
more important it is with a clear formal and unambiguous written
specification. Standards proposals are no different in that respect.

A good proposal has to say exactly what the feature should do, not how
it should do it. (There are many other things a good proposal should
have too, of course.)