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_at_[hidden]>
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_at_[hidden]>
> wrote:
>
>> 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
>>
>