On Fri, Oct 31, 2025 at 2:43 PM Jonathan Wakely wrote:
>
> 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.


I'm not creating this complication. It's already there. Just beefing
out the proposed feature to accommodate all of the possibilities. I'll
admit that 6 and 7 are a bit out there . . . but then maybe you could
have a state machine that must start off in the Home state, and so it
can only be default-constructed, but then you can later move-assign to
it from another state machine. I'm just keeping the door open to all
these possibilities.


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


I glanced over the paper again just now and I think it's pretty clear
what 'std::relocatability' should do, as well as what 'std::relocate'
should do. Sometimes you only need to glance at a possible
implementation to fully-understand what the author's getting at. It's
not like these papers are being sent into outer space where aliens
from another galaxy need to make sense of them. These papers will be
read by proficient C++ programmers familiar with the language who can
attain clarity from looking at a code snippet. That's why I can write
"T should be non-const" instead of the more verbose "the template
parameter type must be non-const" -- because everyone knows we always
use T for the template parameter type. I think it's safe to assume a
certain amount of programmatical common sense (or at least familiarity
with how humans are using C++ on Earth lately).


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


I'm open to suggestions on how to improve the paper. I'll have to find
an alternative to '_Relocate'. Maybe "std_relocate"? So it would be
something like:

class T {
public:
    void std_relocate(T*,T const*, size_t) { . . . }
};


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


I prefer 'int' to an enum, but we can have:

namespace std {
    constexpr int reloc0_cannot = 0;
    constexpr int reloc1_memcpy = 1;
    constexpr int reloc2_compiler = 2;
    constexpr int reloc3_userdef = 3;
    constexpr int reloc4_move = 4; constexpr int reloc4throw_move = -4;
    constexpr int reloc5_copy = 5; constexpr int reloc5throw_copy = -5;
    constexpr int reloc6_move_assign = 6; constexpr int
reloc6throw_move_assign = -6;
    constexpr int reloc7_copy_assign = 7; constexpr int
reloc7throw_copy_assign = -7;
}

Most of the time though, you'd probably just be checking for either
non-zero, or greater than zero, for example:

template<typename T>
requires (std::relocatability< std::remove_reference_t<T> > > 0)
void MyFunc(T &&arg)
{
    // only works if relocate definitely won't throw
}

template<typename T>
requires (std::relocatability< std::remove_reference_t<T> >)
void MyFunc(T &&arg)
{
    // works if T is in any way relocatable (even if it throws)
}