Carrier trait for `?` operator

[nrc]

We accepted an RFC to add the ? operator, that RFC included a Carrier trait to allow applying ? to types other than Result, e.g., Option. However, we accepted a version of the RFC without that in order to get some actual movement and some experience with the ? operator.

The bare ? operator is now on the road to stabilisation. We would like to consider adding a Carrier trait and that will require a new RFC. There is in fact a 'dummy' Carrier trait in libcore and used in the implementation of ?. However, its purpose is to ensure ? is backwards compatible around type inference. It is effectively only implemented for Result and is not intended to be a long-term solution. There are other options for the trait using HKT, variant types, and just existing features. It's unclear what is preferred right now.

One important question is whether we should allow conversion between types (e.g., Result to Option) or whether we should only allow the ? operator to work on one type 'at a time'.

Links:

? operator RFC PR
? operator tracking issue
Niko's thoughts

[Ericson2314]

https://internals.rust-lang.org/t/the-operator-and-a-carrier-trait/ probably work linking too

[nikomatsakis]

I am still a fan of @Stebalien's variant on my original proposal:

enum Carrier<C, R> {
    Continue(C),
    Return(R),
}
trait IntoCarrier<Return> {
    type Continue;
    fn into_carrier(self) -> Carrier<Self::Continue, Return>;
}

Coupled with the "design guidelines" that one should only use the IntoCarrier trait to convert within one set of types. So for example, these would be good impls:

impl<T,U,E,F> IntoCarrier<Result<U,F>> for Result<T,E> where E: Into<F> {
    type Continue = T;
} // good
impl<T> IntoCarrier<Option<T>> for Option<T> {
    type Continue = T;
} // good

But this would be considered an anti-pattern:

impl<T> IntoCarrier<T, Result<T,()>> for Option<T> { } // bad

[mitsuhiko]

I really like this carrier proposal and I would vote in favor of supporting a carrier for option.

One thing that I keep running into as a weirder example currently is the common case of a result being wrapped in an option. This is something that shows up in the context of iterators frequently.

A good example is the walkdir crate. From what I can tell Rust could already express a generic implementation for that case however I wanted to raise this as something to consider.

The case I can see third party libraries implement is a conversion from future to result. What I like about the IntoCarrier is that - if I understand it correctly - it could be implemented both ways by a third party crate: future to result and result to future.

[mitsuhiko]

I implemented a few variants of carrier here to see how it works: https://gist.github.com/mitsuhiko/51177b5bf1ebe81cfdd36946a249bba3

I really like that this would permit error handling within iterators. It's much better than what I did in the past where I had to make a manual iter_try! macro. What do others feel about this?

[nikomatsakis]

@mitsuhiko ah, that's a nice idea to prototype it like that. I also did some experiments in play around type inference and collect -- it seemed like all the types were inferring just as I wanted them, but I feel like I have to do some experimenting to make sure I was hitting the problem cases.

The idea of 'throwing' a result error into Option<Result<...>> is an interesting one! I have definitely been in this situation before and it is annoying; it'd be very nice for ? to just handle it for you. It seems to be kind of skirting right along the line of interconvering between types -- you're introducing a Some, but you're preserving the notion that a Err(x) translates to an Err(x). It's pretty hard to imagine wanting to map Err to None.

I think we will certainly see some other cases where you want to interconvert between "related" types or patterns that have a known semantic meaning.

I also expect that we will get a certain amount of pressure to interconvert Option<T> and Result<T,()> but I am still in favor of resisting that pressure in the general case. :)

[mitsuhiko]

I don't want to start a bikeshed here but I want to throw up some ideas for making the carrier a bit less confusing to people. The carrier primarily exists internally but I assume the docs will sooner or later explain ? and error handling and will have to mention it.

Right now it's Carrier, Carrier::Continue and Carrier::Return conceptionally.

What about it being called a CompletionRecord and the two enums are CompletionRecord::Value (Could also be CompletionRecord::NormalCompletion) and CompletionRecord::Abrupt (Could also be CompletionRecord::EarlyReturn)? These are inspired by the internal values in the JavaScript spec and I think they make things easier to explain and do not overload already existing words. In particular Carrier is super abstract and hard to explain and Carrier::Continue and Carrier::Return for me imply in a way that they would have something to do with the keywords of the same name. Gets especially confusing because Continue holds an unwrapped value and Return a result like object.

I also expect that we will get a certain amount of pressure to interconvert Option<T> and Result<T,()> but I am still in favor of resisting that pressure in the general case. :)

Huge plus + 1 on not adding this. I was originally on the side of supporting this but the more I play around with this and error_chain the more I'm convinced that this will be a source of confusion. It's already easy to foo().or_ok(Err(...))? it.

[seanmonstar]

I also find the Carrier name undesirable.

On Fri, Aug 19, 2016, 8:26 AM Armin Ronacher notifications@github.com
wrote:

I don't want to start a bikeshed here but I want to throw up some ideas
for making the carrier a bit less confusing to people. The carrier
primarily exists internally but I assume the docs will sooner or later
explain ? and error handling and will have to mention it.

Right now it's Carrier, Carrier::Continue and Carrier::Return
conceptionally.

What about it being called a CompletionRecord and the two enums are
CompletionRecord::Value and CompletionRecord::Abrupt? These are inspired
by the internal values in the JavaScript spec and I think they make things
easier to explain and do not overload already existing words. In particular
Carrier is super abstract and hard to explain and Carrier::Continue and
Carrier::Return for me imply in a way that they would have something to
do with the keywords of the same name. Gets especially confusing because
Continue holds an unwrapped value and Return a result like object.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1718 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJF_DJw5VfknCMDUsQW0mRuy1xAYZVks5qhcsxgaJpZM4JnHoi
.

[nikomatsakis]

I dislike the name Carrier, I've just been trying to focus on the core capabilities. I don't find CompletionRecord very intuitive but I like Normal and Abrupt -- I think.

[Stebalien]

Joining everyone in the bikeshed, I agree that Carrier is confusing (I actually have no idea what it means). What about just naming it after the operator: QuestionMark. Not a good name but it's unlikely to confuse anyone.

Also I'm not a fan of Abrupt/Normal because they impose meaning on the operations. There's no reason that an early return is necessarily abrupt or continuing on is necessarily normal. This is why I initially objected to using a Result.

Carrier::Return(X) literally means "please return X immediately" so, IMO, the name is correct. However, EarlyReturn is arguably more accurate.

Carrier::Continue(X) is a bit unfortunate as it has nothing to do with loops (my intention was "please continue with value X". Maybe Proceed? Value (not a verb...)? I don't really know.

[ticki]

@nikomatsakis @Stebalien I don't think a Carrier enum is necessary. Result has essentially the same meaning (one is successful, another is an error/early).

[Stebalien]

@ticki But it's not about success/failure. For example, an iterator returning None isn't an error; it just means that it's done.