Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected

Subject: Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-26 12:25:45

2017-05-26 13:12 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> Peter Dimov wrote:
>
>> Andrzej Krzemienski wrote:
>>
>> > Also, they way I look at this solution is not "when I get this value I
>> > have to check ...", but "when I produce this value I have to make >
>> sure...". Is there no way to acheive this in the language?
>>
>> By not providing a default constructor, I suppose. Otherwise not, there's
>> return value elision so if you do
>>
>> result<T> function()
>> {
>>     result<T> r;
>>
>>     // do things
>>
>>     return r;
>> }
>>
>> nothing is ever called on 'r' on your side if you forget to initialize it.
>>
>
> Actually, there is a way, by providing two types, one
> default-constructible with a singular empty state, one without. In the code
> above, you will still declare the function to return result<>, which can
> never be empty and has no default constructor, but declare `r` to be of
> type result_option, or optional_result, or optional<result>, or whatever.
> Then the `return r` line will convert and check.
>
> (Or you could use `result<result<T>> r` and return `r.value()`, which is a
> funny exercise in ambiguity.)
>

Nice. On the other hand, maybe the solution to this should come in the form
of clever, programmer-assisted, static analysis.

Regards,
&rzej;