On 10/31/25 7:28 PM, Frederick Virchanza Gotham via Std-Proposals wrote:
> 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).

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.

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