On Thu, 24 Apr 2025 at 11:37, Andrey Semashev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 24 Apr 2025 11:22, Jonathan Wakely wrote:
> >
> > On Thu, 24 Apr 2025, 08:56 Andrey Semashev via Std-Proposals, <std-
> > proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> >
> > I often find std::optional a disappointment in practice. In objects with
> > lots of std::optional members,
> >
> > That isn't the situation that was given as motivation by the OP though.
>
> The motivation presented by the proposal author doesn't have to be
> exhaustive. Other people may have other reasons to find the proposal
> useful. I just gave one.
>
> > it nearly doubles the object size due to
> > padding, and I often find myself replacing it with separate T members
> > and bools or even std::bitset. This is, of course, tedious and requires
> > discipline on the user. It also needs T to be cheaply constructible,
> >
> > Why? You would construct it with nullopt to avoid the default construction.
>
> Again, that would entail all the costs of std::optional with it. And I
> just said that those costs can be unacceptable.
>
> > and
> > could benefit from a proposal like this one.
> >
> > I don't really see how.
>
> The benefit would be the ability to cheaply construct an object that
> would otherwise be expensive to construct.

Ah sorry, I misread your comment as saying that std::optional would
benefit from this feature. I agree that alternatives that don't use
optional could benefit. But I still think "just use optional" is the
right answer in general. If you need something more specific for some
cases, you can do that, but I'm not persuaded that something like
std::moved_from should be standardized.