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


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


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