Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 16:07:59
>> I have been persuaded by argument here that default construction to
>> empty is in fact a defect in the design. The formal empty state ought
>> to *always* be explicitly constructed, and **never** occur implicitly.
>> I have logged this defect to
> I don't think I agree with that. The whole point of having a singular
> empty state is to default-construct to it so that the mistake of failing
> to assign to the default-constructed result/outcome can be detected. This:
> result<T> function()
> result<T> r;
> // do things that put something into r
> return r;
> where the "do things" part sometimes fails to put something into r.
But you still get exactly that *if* you ask for it:
// do things that put something into r
Combined with the never-empty guarantees, this new behaviour makes the
empty state completely impossible unless someone asked for it at least
once somewhere. I like that.
> If you don't default-construct to empty, you pretty much lose the point
> of having empty.
I am currently minded that default constructing an outcome or result is
not possible if T does not have a default constructor. If it does, it
default constructs to a default constructed type T.
This matches the current behaviour of Expected, though Vicente is
currently planning on eliminating the default constructor entirely. If
he gets LEWG buy in to that design, I am minded to match Expected on
this in outcome/result: no default constructor, not ever.
The reason my opinion has been changed on this is that I cannot think of
any situation where you really need a default constructor or else
everything blows up and the end user reaches a showstopping game ever
situation. If someone can suggest one, I think we'd all change our opinion.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk