28 Apr
2013
28 Apr
'13
7:31 p.m.
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. > > 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