Or, for specifics on how I propose we think about this, Maciej’s comments here:

> Since we do not introduce new types of references, or new types of
> member functions, we can gradually migrate code from calling std::move
> to using reloc operator (while preserving ABI and API compatibility).
> This will also allow to finally have a optimal construction for types

Are appropriate. It is forward-looking, stable and minimal.

Full context:

> Hi,
>
> I don't think adding yet another reference type and yet another
> special member function is a good way to solve this, as the complexity
> in this area is already big. I think the solution should reuse as much
> as possible of existing syntax.
> What I think would be better, is that we kept move-constructors, but
> we add a new syntax to mark if a class is relocatable:
> MyClass(MyClass&& other) = relocate;
>
> Marking such a constructor as relocate (no user-provided definition
> allowed), would indicate to compiler two things: 1) moving is just a
> trivial memcpy, 2) moved-from object is left in a state (e.g. default
> constructed) where destructor call has no-side effect.
> So current code:
> MyClass newObject(std::move(other));
>
> becomes (pseudo-code):
> MyClass newObject = uninitialized;
> new (&newObject) MyClass(other); // or memcpy
> new (&other) MyClass();
> // when 'other' goes out of scope, its destruction can be skipped
> because it is a noop.
>
> So far it does not change anything w.r.t. what we have now.
> But if we add Sebastian's proposed operator reloc with such a
> semantics that it will call move-constructor, and mark source object
> as already destroyed we get the semantic checking that moved-from
> object cannot be used anymore.
> Operator reloc can be called on any type that is move-constructible,
> it is just that for types marked as relocatable such an operation can
> be better optimized.
>
> MyClass newObject = reloc other;
> // now other cannot be referenced any more
>
> Since we do not introduce new types of references, or new types of
> member functions, we can gradually migrate code from calling std::move
> to using reloc operator (while preserving ABI and API compatibility).
> This will also allow to finally have a optimal construction for types
> with user-defined constructors:
>
> struct Person
> {
> Person(std::string firstName, lastName)
> : firstName(reloc firstName)
> , lastName(reloc lastName)
> {}
>
> std::string firstName, lastName;
> };
>
> Person p1("John", "Doe"); // no temporaries, no move constructors
> Person p2(p1.firstName, p2.lastName); // one copy, no temporaries, no
> move constructors
>
> Regards,
> Maciej
>
> wt., 1 lut 2022 o 11:04 Gašper Ažman via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):

WL

> On Feb 2, 2022, at 4:43 AM, William Linkmeyer <wlink10_at_[hidden]> wrote:
>
> The larger picture here seems to be an effort to make move semantics friendlier and easier to use. I began an informal survey on open-std of papers on move semantics.
>
> After reading unrelated papers, though, the thought occurred that move semantics will:
> 1. move semantics are becoming more implicit (defaulting to move where applicable) and unified (utilities for move-based alternatives in the language are becoming prevalent)
> 2. we should consider that, in a decade or so, move semantics may become more than a friendly memcpy/delete, and
> 3. papers on move semantics should be weighed against the requirements they may place *on* the ABI
>
> To illustrate the first point:
> - a proposal for (more) move semantics in views: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p2446r1.html
> - a paper describing move semantics at scale (esp. in containers): http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p2329r0.pdf
> - “proposes a conservative, move-only equivalent of std::function”: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p0288r9.html
> - a proposal for simpler implicit move in return statements (clarifying c++20’s implicit move): http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p1018r13.html#biblio-p2266r1
>
> The second point is speculative by its nature. Papers are often reflective on the past or aspirational for the relatively near future.
>
> I am proposing that, in a decade or so, it is not unlikely that:
> - memory will be far more distributed than it is today
> - processors, not processor cores, often of various types will share memory — such as a GPU sharing memory with the CPU, or a Docker Swarm of several computers
> - transactional memory will become more prevalent, perhaps becoming incorporated into the standard with a similar speed as move semantics are today
>
> To illustrate these speculations, here are some papers:
> - module distribution, which blurs the line between platform-specific source code and abstract packages: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2473r1.pdf
> - freestanding, embeddable c++: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p2338r0.html
> - minimalist transactional memory: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p1875r2.pdf
>
> These papers are meant to illustrate a trend towards scale-independent processing with highly distributed programs.
>
> It would be prudent, therefore, to think in terms of patterns that are implementable in that context so as to avoid painful ABI breaks in the future, imposed on ourselves.
>
> I am merely urging people more fluent than myself to consider a set of move semantics generic enough to be future-proof on platforms where it *is* analogous to pass a reloc operator into a function that has a 50/50 chance of actually relocating it or not.
>
>
> WL
>
>>> On Feb 1, 2022, at 4:07 PM, Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>> 
>>
>>
>>> On Tue, Feb 1, 2022 at 4:04 AM Gašper Ažman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>> Hi Sebastien,
>>>
>>> you sure made a pretty long write-up! What I'm missing on the first skim-through is a thorough review of the currently published papers in the space and answers to the previously surfaced objections.
>>>
>>> Some of the papers in this space:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1144r5.html
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1029r3.pdf
>>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0023r0.pdf
>>
>> Also, for instance, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html has a section on Pilfering. Boost.Json uses that approach, for instance (probably other stuff in Boost too, haven't checked).
>>
>> Barry
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals