Hello everyone,

I reworked my first proposal about relocation (with a dedicated constructor and reloc operator). You can find the updated proposal here: https://github.com/SebastienBini/cpp-relocation-proposal/blob/main/relocation.pdf

The main changes are:
- added comparison against related existing proposals.
- in order to preserve the ABI: the relocation constructor and reloc operator no longer early destruct instances.
- put a better emphasis on possible memcpy optimization (trivial relocation, building on top of P1144R5 from Arthur O’Dwyer).
- also, build up a case for classes that shouldn't be copyable nor movable, but can be relocatable.

About the last point, here is a quick overview: consider a class that guarantees (unique) ownership over some resources (i.e. allocated in constructor or otherwise throws, and deallocates in destructor). Basic examples are a non-null pointer class or a socket wrapper class. In a pure class design perspective:
Thank you & best regards,
Sébastien

On Wed, Feb 2, 2022 at 10:53 AM William Linkmeyer <wlink10@gmail.com> wrote:
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@lists.isocpp.org> napisał(a):

WL

On Feb 2, 2022, at 4:43 AM, William Linkmeyer <wlink10@gmail.com> 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

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@lists.isocpp.org> wrote:




On Tue, Feb 1, 2022 at 4:04 AM Gašper Ažman via Std-Proposals <std-proposals@lists.isocpp.org> 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:

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals