Well, you should start by reading the list of articles under https://isocpp.org/std/ - if you haven't already.

I'm assuming that you and Stormshield are domiciled in France? If so your national standards body is AFNOR and the good news is that AFNOR has a C++ subgroup[1] and its members are active in C++ standardization - some names you may be familiar with include Jens Gustedt, Joel Falcou, Gabriel Dos Reis, Corentin Jabot etc. I gather that AFNOR has regular meetings to discuss C++ standardization so a useful step would be to attend those meetings either in person or by video to introduce yourself and perhaps present your proposal in front of a smaller audience in an informal context. At some point you might want to seek affiliation to AFNOR/CN CPP on behalf of Stormshield.

1. https://norminfo.afnor.org/structure/afnorcn-cpp/langage-de-programmation-cpp/119670

On Mon, 5 Sept 2022 at 13:29, Sébastien Bini <sebastien.bini@gmail.com> wrote:
Hi Edward,

Thank you for the thorough explanation. That should keep me busy for quite some time :)

Unfortunately, I and the company I work for (Stormshield) are not affiliated with any standards organization. Would you or anyone on this list have some documents describing that standardization process?

This being my first proposal, and quite a large one, it would be a gargantuan task to carry it on my own. I hope that, as it gets more light, more people (hopefully standardization champions) will bring their support (just like you have been doing).

Thank you for your help with this proposal. I'll gladly contact you when I have a complete draft. Thank you again!

Best regards,
Sébastien

On Mon, Aug 29, 2022 at 6:42 PM Edward Catmur <ecatmur@googlemail.com> wrote:
On Wed, 24 Aug 2022 at 09:59, Sébastien Bini <sebastien.bini@gmail.com> 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