On Thu, 4 Jun 2020 at 02:20, Ville Voutilainen <ville.voutilai...@gmail.com> wrote: > > On Thu, 4 Jun 2020 at 02:13, Marc Glisse <marc.gli...@inria.fr> wrote: > > > > On Thu, 4 Jun 2020, Ville Voutilainen wrote: > > > > > On Thu, 4 Jun 2020 at 01:52, Marc Glisse <marc.gli...@inria.fr> wrote: > > >> > > >> Hello, > > >> > > >> is there any drawback to the attached patch? It changes the code > > >> generated for > > > > > > I don't get it. The noexceptness of the defaulted default constructor > > > should be a computation > > > of the noexceptness of the subobjects, and that should boil down to > > > whether optional's storage > > > is noexcept-default-constructible. And that thing has a noexcept > > > default constructor. Why > > > does this patch change anything? > > > > "noexcept" is a red herring, what matters is defaulted vs user-provided. > > In one case, we end up zero-initializing the whole buffer, and not in the > > other. > > Yes, I just came to that conclusion. This is value-init, so the > language manages to zero-init the whole-object, > but with the change, it just calls a user-provided constructor. > That'll then merely boil down to value-initializing just the _Empty > part > of the _Storage in _Optional_payload_base. We are in > http://eel.is/c++draft/dcl.init#8.1.2. The change takes us > to http://eel.is/c++draft/dcl.init#8.1.1.
Ha, and optional's default constructor isn't even specified to be defaulted.
