The motivation section and the entire text document are thin, because the
whole problem is not a big deal.
Either the compiler allows to declare methods outside of the class
definition, or not.
Was it done on purpose in the language? I'm not sure. It may just be
something that the authors forgot to do.
I wanted to add my 5 cents, which is a small correction of the semantics of
the language.
This fix is very useful and attractive because it makes it easier to
separate the interface and the implementation.
I never said that this proposal is the only way to do that.
The proposal helps to simplify this separation, since the existing methods
are either over-complicated or less effective.
I also addressed the concern of the declaration mismatch and wrote that it
leads to the same error as in case of plain function - the linker error.
That is what I have. Again, the whole issue is small and clear, and I
cannot add anything more.
If it is not acceptable, then I give up.
I agree with you that I failed to convince people. This is because of my
insufficient experience and poor English.

I am ready to answer any relevant question, but I see I cannot make
progress.
If someone wants to continue with it, then I really wish good luck, and I
will support him.
I thank everybody who interested and participated.

чт, 26 авг. 2021 г. в 17:46, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]>:

> On Thursday, 26 August 2021 06:19:28 PDT Jason McKesson via Std-Proposals
> wrote:
> > When Thiago asked you to write a proposal, I'm fairly sure he didn't
> > mean for you to just take a couple of sentences from this thread and
> > throw them into a text file. What we want is something more specific,
> > more comprehensive as to the behavior of the feature, and which
> > addresses the issues raised in this thread.
>
> To be clear: I agree with Valery that there's a need. I've needed this
> before;
> we use private implementation techniques all the time, with severe hacks
> to
> reduce the number of memory allocations.
>
> I'm not arguing to put a roadblock in the request.
>
> I'm saying that the discussion on the mailing list will not lead to a
> fruitful
> result. Someone needs to take the next step and write a very good paper.
> And
> as any paper that addresses core language changes, it needs to provide
> sufficient evidence for why this is a good idea, why the status quo needs
> to
> change (like explaining what hoops developers need to go through), go
> through
> the possible concerns the committee may have, explaining how they're
> addressed, and in addition to the recommended syntax, provide alternatives
> that were discarded.
>
> I think the CWG has an incubator team that can help you write and improve
> on
> the paper.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>