Usually you would fix the left type and only keep the right type variable. `then` looks like it’s a combination of what in other languages / libraries may be two separate methods called `map` and `flatMap` (or `fmap` and `bind` in Haskell). Here however, we are only interested in the `flatMap` case, because only that involves another Future and therefore a potentially different error type. Let’s look at the type signature of `flatMap`/`bind`
m a -> a -> m b -> m b so in our case Future a -> a -> Future b -> Future b So if we introduce the second type parameter now, we couldn’t satisfy this signature anymore, unless we fix the additional type, i.e. Future e a -> a -> Future e b -> Future e b The `Either<E1,E2,E3>` case would be problematic. How many operations would we allow? How would one handle `Either<E1…E50>`? Best, Dario > On Apr 7, 2016, at 2:36 PM, Benjamin Mahler <[email protected]> wrote: > > Long overdue, thanks Michael! > > Have you considered how composition will work with typed errors? I recall > in the past when we looked into this, Future chaining was interesting: > > f1 = []() -> Future<T1, E1> { ... }; > f2 = []() -> Future<T2, E2> { ... }; > f3 = []() -> Future<T3, E3> { ... }; > > f1().then(f2).then(f3) // what does this yield? Future<T3, > Either<E1,E2,E3>> ? > > We don't have chaining with Try right now, but we ideally want to support > it. Any thoughts? > > On Mon, Apr 4, 2016 at 6:48 PM, Michael Park <[email protected]> wrote: > >> Contrary to standard C++ practices, Mesos uses return values as the >> mechanism >> for error handling rather than exceptions. >> >> This proposal is simply an evolution of the current mechanism we have in >> Mesos today. >> This direction is consistent with the designs made in Rust, which uses >> return values as >> the error handling mechanism at the language level. >> >> The first step is to add an additional template parameter to class template >> *Try*, to get *Try<T, E>*. >> >> The proposed design defaults* E *to *Error*, and requires that *E* be, or >> is inherited from *Error*. >> The return type of *error()* is *const std::string&* if *E == Error* and >> *const E&* otherwise, >> for backwards-compatibility reasons. >> >> So in the end, *Try<T>* behaves exactly as before. >> >> The work is being tracked in MESOS-5107 >> <https://issues.apache.org/jira/browse/MESOS-5107>, and i've written a >> quick design doc >> < >> https://docs.google.com/document/d/1tG21sD-ZX64FHAKJwhEPk6JkgsBIv12AmA1Y3J0kCYY/edit# >>> >> capturing >> some of the preliminary thoughts on this topic, and a proposal for an >> immediate use case >> for the Windows work. >> >> If you're interested in how Rust deals with error handling, check out >> https://doc.rust-lang.org/book/error-handling.html. Our *Option* is their >> *Option*, >> our *Try* is their *Result*, and they don't have our *Result*. >> >> I'm going to be pushing the changes proposed shortly, but the changes are >> small and >> does not require a large sweeping changes or anything like that. >> So please reach out to me with your concerns and complaints and I will be >> sure to address them. >> >> Thanks, >> >> MPark >>
