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

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Pierre T. (ptalbot_at_[hidden])
Date: 2013-04-28 16:24:05

On 04/28/2013 09:31 PM, Vicente J. Botet Escriba wrote:
> 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>.
IMHO, a member method is better because it can be chained any where in 
the chain. I also prefer the method taking continuations as it enables 
void return function.
>>
>> 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?
Of course, it's an excellent idea. I'll try to update my proposal by 
tomorrow.
>>
>>>> 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
>
Best regards,
Pierre T.