Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-08 11:36:19

>>>> Why does it need to be identical?  Can't you just use
>>>> decltype(r.error())?  As long as you know that at minimum it supports
>>>> the error_code interface this should be sufficient for most purposes.
>>>
>>> It doesn't work unfortunately because you need to convert from
>>> error_code interface compliant type A to error_code interface compliant
>>> type B, and what does "convert" mean exactly? Remember, the TRY
>>> implementation can have no knowledge of what the return type of the
>>> enclosing function is.
>>
>> There was talk (not sure if it was an official proposal or just a
>> suggestion) of something like
>> decltype(return)
>> for getting the type returned from the current function.
> 
> Even without that, couldn't TRY accept the return type as a parameter?

It doesn't especially help you in practice. What Outcome currently does
is return magic type sugar from TRY which is implicitly constructible by
any basic_monad instance, this works around needing to know what the
return type is for the calling function in the TRY implementation.

> Besides, if the intent is to convey the payload up the call chain, then
> it can be left to the responsibility of the method itself to forward
> that appropriately -- ie. if you call something that can return an
> error_code_info<EI1> then you are required to do one of the following:
> 
>   1. Deal with the error locally, not calling TRY.
>   2. Call TRY to pass on the error unmodified, thereby requiring that
> you also return an error_code_info<EI1>.
>   3. Pass on the error, but returning error_code_info<EI2> where EI2 is
> constructible from EI1 (forwarding the original payload plus some
> additional context).  This might be a special case of #1.
> 
> (By "returning" here I don't mean directly, I mean wrapped in a result<>
> or outcome<>.)

Of course you could do all that.

What I'm saying is that for 95% of programmers, when facing the choice
of whether to use different E types in exchange for typing a ton load
more boilerplate all day long every day in everything they write, they
will - I guarantee you - choose just to make the error type the same
throughout the entire program. It makes things *simple*.

All that said, given that my non-variant Outcome plan has much more
compile time budget than before, I certainly can make constructors all
templated and SFINAEd in a way presented Outcome could not without
blowing out compile times. One therefore could enable implicit
construction from some arbitrary other error type if the user has
implemented implicit conversion between error types. I think that would
enable what you are proposing?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/