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