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

Even in the 20th century there was broad general consensus regarding the
value of naming constants so if this paper wants to keeps the magic numbers
there will need to be strong justification.

The reloc named constants you provided still have these magic numbers in
the name which is a bit odd.

Jeremy

On Fri, Oct 31, 2025 at 18:26 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> 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).
>
>
> > 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)
> }
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>