On Wed, 24 Aug 2022 at 09:59, Sébastien Bini <sebastien.bini_at_[hidden]>
wrote:

> Well, unless I am missing something, it looks like we clarified all the
> blocking points so far? Thanks for your help in moving this forward!
>
> What are the next steps? I guess another revision of the proposal needs to
> be written?
>

Yes, another revision of the proposal, ensuring that it covers:

   - acknowledgement of and references to previous and current proposals in
   the space
   - motivations (performance, safety/correctness, composability) with
   explanation why other proposals fall short
   - justification for each of the subfeatures: relocating constructor,
   relocating assignment operator, reloc keyword, try-with-init
   - specification of special member functions when (a) unspecified, (b)
   declared as defaulted, (c) defined as defaulted, (d) deleted, (e)
   user-defined; their interactions with the presence and noexcept
   qualification of the other special member functions; and the behavior of
   the user-defined relocating constructor for bases-and-members not specified
   - specification of reloc operator with regard to: loops; gotos;
   branches; sequencing within expressions; logical and ternary conditional
   expressions; hiding; error detection (making subsequent use ill-formed, not
   just UB); discarded-value expressions; function parameters vs. local
   variables
   - discussion of ABI implications and steps taken to ensure that ABI does
   not break unexpectedly and that Standard Library (and third-party library)
   implementations can attain as much benefit as possible consistent with
   preserving ABI
   - discussion of implementation techniques for relocating assignment
   operator: destroy-and-rebuild, copy-and-swap (and Just Swap), union
   technique (for the overconfident)
   - suggestions for type traits and concepts
   - suggestions for additional API for Library containers to make use of
   this feature (e.g. optional::pop, T vector::pop_back,
   make_from_tuple(prvalue))
   - suggestions for internal changes to Library (e.g. vector making use of
   trivial relocation to reallocate) possibly affecting Library API in visible
   ways (e.g. noexcept)
   - identification of further direction: defaultable swap (with Library
   interaction), perfect forwarding of prvalues
   - example code, written in terse, non-motivating style (single-letter or
   meaningless class, variable and function names) suitable for insertion into
   the Standard to clarify points and serve as implementer test cases

Ideally we would also have a sample/reference implementation, compiler and
standard library, along with test cases; I may be able to devote some time
to this.

Hopefully it goes without saying that the proposal should have its source
text version-controlled and be typeset in a recognized style; many people
use Bikeshed (https://tabatkins.github.io/bikeshed/) which takes Markdown
and outputs HTML, while others use LaTeX outputting to PDF (I'm not sure
exactly what styles they use).

With regard to motivation, I would suggest starting with the existence of
types that are (trivially) relocatable but not movable, e.g.
gsl::non_null<std::unique_ptr<T>>, noting that these types are currently
practically unusable despite being important to correctness, then noting
that while the other outstanding proposals for trivial relocation would
make some uses possible, they would no longer be composable with other (non
trivially-relocatable) types, the situation requiring a relocation
operation with appropriate (memberwise) behavior for aggregate (Rule of
Zero) class types and the possibility of user-defined behaviors (e.g. for
std::string). Then noting the additional requirement of a relocating
assignment operation (since the copy and move assignment operations require
the source object to be left in a destroyable state), and arguing for
relocating constructor and assignment operator with respective signatures
of T(T) and T& operator=(T) by parallel with the tripartite classification
of value categories, and apologetics for the parameter aliasing its
argument. Then demonstration of how this syntax can be used to accomplish
the (mostly performance) goals of trivial relocatability (by defaulting the
relocating constructor at declaration). Then discussion of why the reloc
keyword is necessary to work with relocatable non-movable values, and
demonstration of how it adds value by preventing bugs (use of moved-from
variables, when used in place of std::move). Justification of
try-with-init can probably wait until specification of the relocating
assignment operator.

Finally, are you affiliated with ISO/IEC JTC1 SC22 WG21, possibly via your
National Body (NB, your national standards organization)? While supposedly
not an absolute necessity, in practice it's essential for a proposal
(especially one as wide-ranging as this one) to have (multiple) champions
with formal affiliation and a record of participation, ideally both au fait
with the standardization process and having prior experience successfully
getting features into the Standard.

Feel free to contact me here or off-list to write or review parts of the
proposal; for assistance getting it published; or if you have thoughts
about a sample/reference implementation. Good luck!

Ed Catmur