On Thu, 24 Apr 2025 at 18:11, Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 24 Apr 2025 17:59, Ville Voutilainen wrote:
> > On Thu, 24 Apr 2025 at 17:48, Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >
> >> The value of the proposal would be standardizing the protocol for
> >> creating moved-from objects. This would be useful for generic
> >> programming, where the user would be able to create moved-from objects
> >> from any library that supports the protocol (whether it is the standard
> >> library or not).
> >
> > How generic is that? If a type doesn't opt in, what happens? Is the
> > result ill-formed, or a well-formed break in the attempted generality
> > where you just won't get the benefits you thought you get?
>
> It depends on the intention of the developer. If a type doesn't support
> this protocol, it indicates that it can't be constructed in a moved-from
> state. This might fail to compile (if this support is mandatory for the
> generic code), or there may be a different (arguably, less efficient)
> code path.

Right. Neither of which is generic, and if there's an "it might be
well-formed, it might not be" is even
less generic.

> The point is that the "fast" path would be fast and portable, instead of
> having to hard-code support for various types.

Alrighty then. We should then perhaps look at some actual algorithms
where that's beneficial, and how this proposal
actually achieves those benefits in its proposed form, and why that
form is better than other alternatives, like a tag-typed
constructor. And then we likely have something that looks very much
like the whole allocator-aware-types model of standard
C++, and we need to ask whether having such a standardized model is,
well, sufficiently useful to be standardized.