On Fri, 31 Oct 2025 at 14:02, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Oct 31, 2025 at 7:54 AM Jonathan Wakely wrote:
> >
> > The standard is not defined in terms of "a possible implementation".
>
>
> When I provide an implementation in a paper, it's for a few reasons:
>
> (1) The code itself can be explanatory, and might clarify any doubts
> or questions the reader has.
>

It certainly didn't do that.


> (2) The code can "bring the feature to life", in that the viability of
> the feature can be made more real in the eyes and mind of the reader,
> particularly if the paper is being read by a compiler programmer who's
> wondering how much work it will be to implement the feature. If I can
> show an easy straight-forward implementation, a compiler programmer
> might lose interest less readily.
>
> Some people write a paper and just give the specs of what the feature
> should do, and leave it to the reader (and to the compiler programmer)
> to use their imagination to code it. I give both the specs and a
> possible implementation.
>

There is no spec. You've listed 13 ways to do something, with no discussion
comparing them or demonstrating why so many are needed. I realise the
number is doubled by the nothrow variants, but six is still a lot of
conditions to handle in every container-like type. Then you've provided
code to implement it. There's no design here that I can see, certainly no
clear specification of what the semantics are supposed to be, except for
"possible implementation".

You can argue about it, but I'm trying to tell you that's not how you write
proposals to convince the committee to do something this novel.


>
>
> > What are the semantics you're proposing? Are you proposing that
> > the reserved name _Relocate have special meaning? (Why?)
>
>
> I went with "_Relocate" because all underscore-followed-by-capital
> names are restricted. I didn't choose "relocate" or "Relocate" because
> I know that some classes might already have a method called "relocate"
> that does something else (e.g. a class for a banking customer that has
> a method to move their account to a different branch).
>
> I think my paper is quite clear in that the standard library function,
> "std::relocate", will invoke the static member function "T::_Relocate"
> if it exists, but nonetheless I've edited my paper just now to make it
> more clear.
>
>
> > And that there should be a magic special case for arm64e that doesn't
> handle any future
> > architectures that have similar behaviour?
>
>
> What we would have is a preprocessor if-else ladder, something like
>
> #ifdef __ARM64E__
> if constexpr ( __builtin_query_resign_vptr_on_reloc(T) ) { . . . }
> #elifdef __SOME_OTHER_ARCHITECTURE
> else if constexpr ( __builtin_something_futuristic(T) ) { . . . }
> #endif
>
> I've edited my paper now again to show this preprocessor if-else ladder.
>

Again, too much implementation detail, not a designed set of semantics.


>
>
> > This seems far too focused on specific implementation details that
> you've observed, and not on a useful design.
>
>
> I think the design is quite clear, but nonetheless I've edited the
> paper again just now to be a bit more descriptive:
>
> https://www.virjacode.com/papers/relocatability.htm
>
> I've also added +7 and -7 to the return values for copy-assignment
> instead of move-assignment.
>

Oh good, more cases to handle!

Is everybody just supposed to memorize the numbers and what they mean (and
which ones don't have a nothrow version)? Would an enum be better? Maybe a
bitmask type so that a nothrow flag is OR'd to the choice of
implementation? Again, this hasn't been designed, it's just a possible
implementation dumped onto paper.