Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-28 15:31:24

Le 28/04/13 20:17, Pierre T. a écrit :
> On 04/28/2013 07:30 PM, Vicente J. Botet Escriba wrote:
>> Le 28/04/13 18:27, Pierre T. a écrit :
>>> On 04/28/2013 05:20 PM, Vicente J. Botet Escriba wrote:
>>>> Le 28/04/13 16:22, Pierre T. a écrit :
>>>>> On 04/27/2013 03:30 PM, Vicente J. Botet Escriba wrote:
>>>>>> Le 27/04/13 09:39, Pierre T. a écrit :
>>>>>>> On 04/26/2013 08:17 PM, Vicente J. Botet Escriba wrote:
>>>>>>>> * Default Constructor or constructor from nullexpect
>>>>>>>> What is the advantage of having a expected instance that doesn't
>>>>>>>> have
>>>>>>>> neither a value nor an exception?
>>>>>>>> How would the user manages with this possibility?
>>>>>>>> Are you looking to make expect movable?
>>>
>> Humm, I don't know if this is enough.
> I'll drop the default constructor for the moment. When an 
> implementation will be available, feedback from users will help to 
> find relevant use-cases.
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> *Ah I think I see now what was the initial intention. I 
>>>>>>>>>>>> suspect
>>>>>>>>>>>> that you mean that as the result of e.then(f) would 
>>>>>>>>>>>> transport the
>>>>>>>>>>>> exception stored on e if e is not valid, then the exception 
>>>>>>>>>>>> would
>>>>>>>>>>>> be relayed until there is a call to visit_error and no call to
>>>>>>>>>>>> any function will be done.
>>>>>>>>
>>>>>>>
>> Humm, in the example I gave above f an g are not continuations but
>> expected<> producers.
>> Anyway, the variadic version of then could have its uses. I like it, but
>> it is orthogonal to the when_all feature.
>>
>> What do you think about letting the continuation returning an
>> expected<>? It has the advantage to allowing the continuation to
>> transport exceptions also without throwing.
>>
> I forgot to claim the change but in my "then" version, the function 
> passed to "then" must return an expected (or void). So all functions 
> are expected producers. It's strange to return something else because 
> it would always be a good value into an expected. The "then" chaining 
> could not return error cases.
>
> I don't think there are much differences between when_all and then(f,g).
There are some :)
* when_all() is a free function, expected::then is a member function.
* when_all() takes expected as parameters, while then() takes 
continuations having as parameter the expected value.

They have in common that the result could be an expected<tuple>.
>
> However, I propose to let this feature out of the GSoC proposal. But 
> of course, we wouldn't let it out of the summer, it's just because 
> time is lacking and adding features in a hurry could break the 
> proposal consistency.
You could add them as COULD features if there is enough time (not on 
plan). I would prefer if these features were in the priority SHOULD.
BTW, could you classify the features of your proposal as MUST/SHOULD/COULD?
>
>>> About the "inspect" method, I try to find another name instead of
>>> visit_error because it makes me think to the pattern visitor which is
>>> too specific to hierarchy classes. I found that inspect was nice
>>> because it's like in a factory where the chief "inspects" that
>>> everything has been alright.
>>>
>> The name should work independently of the name of the 'then()' function.
> Oh nice remark.
>>
>> on_exception? if_exception? catch_all? capture?
>>
>>
>>
> I would say "on_error", so it would be a generic name for error type 
> that aren't exception.
>
>
yes, why not?

Best,
Vicente