+1 well done!!

WL

> On Apr 29, 2022, at 12:08 PM, Sébastien Bini via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> 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:
> those classes shouldn't be copied as they provide unique access to the resource.
> they could be movable but that's not ideal. The move constructor may leave them in a dirty state or else rely on complicated mechanisms not to do so. The move constructor for such classes:
> either breaks the class guarantee. That is the case if the resource is moved from one instance to the other, leaving the original instance with an invalid resource. As stated this breaks our class invariant, which is to always offer unique access to some resource.
> either needlessly complicates class design to work around the naive implementation described above. This may include allocating new unique resources to the moved instance in the move constructor, or to do it lazily at a later stage the next time the moved instance is reused.
> may not be appropriate. What would you do with a moved-from socket wrapper instance? You don't know whether it owns any socket, and if it does, it will probably be on something you don't want. Most of the time, C++ programmers just discard moved-from instances anyway as they are unsure of what they contain.
> it is a legitimate need to be able to "move" them around.
> the relocation constructor fits this need: the classes can be relocated to another location. As the relocated instance is guaranteed never to be touched again, the relocation constructor can leave the relocated instance in a dirty invalid state (which the move constructor cannot).
> Thank you & best regards,
> Sébastien
>
>> On Wed, Feb 2, 2022 at 10:53 AM William Linkmeyer <wlink10_at_[hidden]> 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_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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals