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:23:02

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

> Andrzej Krzemienski wrote:
>
> This is only one way of looking at it. Another one is that I have function
>> like, `open_file`, I want it to either return the file handle or the
>> information about run-time situation that prevented opening the file.
>> "reading from uninitialized `expected`" is no such situation: it is simply
>> a bug.
>>
>
> As I say in the paragraph immediately before, if your open_file calls
> open_file_impl, feeding it invalid arguments, this is simply a bug. Yet
> when open_file_impl returns EINVAL to indicate invalid arguments, and you
> return that back to the caller, you end up in the exact same situation.
>

And I feel that something is wrong with all these artificially wide
contracts: std::sqrt() is well defined for any number, including negative
ones. Maybe sometimes it is the worse of the two evils, but implementing
this in `expected` (I mean this yet annother error code, I guess I must
accept expected's wide contracts), wil impose this quesionable choice on
everyone.

Regards,
&rzej;