To be honest, std::optional is not the most performant code, see following
for std::varian, which is similar.

https://stackoverflow.com/questions/62404209/why-does-clang-handle-exceptions-for-this-trivial-stdvariant-code

but you can always use a char / byte array and use placement new - will be
more difficult to code, but in this way you will be able to know "what
happens" all the time.



On Wed, Sep 2, 2020 at 10:43 PM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, 2 Sep 2020 at 22:35, Steve Hearnden via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Thanks for your replies. I think that std::optional is similar to what
> I was thinking about, but was requesting an extension to C++ to produce
> different behaviour.
> > The implementation of std::optional with my Microsoft compiler has a
> union which is something like....
> > union {
> > char _Dummy;
> > T _Value;
> > };
> > This is an excellent example of my use-case. The code in the library
> has to side-step the behaviour of the compiler of constructing items, and
> would be replaced by my proposal with ....
> > [[unconstructed]] _Value;
> > We would simplify implementations of std::optional, focusing on the
> behaviour we require, rather than hiding from the compiler the use cases.
>
> Well, anecdotally, at least one maintainer of std::optional doesn't
> need another way to spell "union". The same maintainer
> calls into dispute the suggestion that this facility simplifies the
> implementation of std::optional, because the pre-c++23 versions
> of it would need to use a union anyway.
>
> Having a core language attribute with semantic effects seems like a
> very poor way to support something as uncommon
> as this, especially when it's just another way to spell
> already-existing ways to implement the same thing.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>