On Wed, Nov 5, 2025 at 4:42 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

You missed one other reason - what if the implementation has a bug?

Of course the problem solves itself - if the implementation is the
specification, it is impossible to have a bug!

-- 
Be seeing you,
Tony