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 https://github.com/ned14/boost.outcome/issues/44.
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: result<T> function() { result<T> r(empty); // do things that put something into r return 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/