Use a Carrier trait with the `?` operator #33389

nrc · 2016-05-03T20:35:56Z

Allows use with Option and custom Result-like types.

Note that this part of RFC 243 did not get approved, so this PR is just for experimentation purposes.

This supports conversion between result types when they have the same number of type args, but not otherwise (e.g, Result to Option), that requires #33108

Part of #31436

rust-highfive · 2016-05-03T20:36:09Z

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

durka · 2016-05-03T21:07:26Z

The big thing for me isn't Result <-> Option -- I'd like to experiment with some kind of DebugResult that builds up a backtrace as it passes through question marks.

jimmycuadra · 2016-05-03T23:32:47Z

src/libcore/ops.rs

@@ -2155,3 +2157,126 @@ pub trait BoxPlace<Data: ?Sized> : Place<Data> {
    /// Creates a globally fresh place.
    fn make_place() -> Self;
 }
+
+/// A trait for types which have success and error states and are meant to work
+/// with the quiestion mark operator.


quiestion --> question

durka · 2016-05-04T18:27:03Z

src/test/run-pass/try-operator-custom.rs

+}
+
+fn g(x: i32) -> MyResult<i32, String> {
+    let _y = f(x)?;


this was supposed to be x-1 (or on line 46)

it terminates with the given input, I don't care too much about it being a sensible program

Yeah, it terminates with a stack overflow...
On May 4, 2016 4:49 PM, "Nick Cameron" notifications@github.com wrote:

In src/test/run-pass/try-operator-custom.rs
#33389 (comment):

MyResult::Terrible(e) => T::from_error(e.into()),

}

}
+}

+fn f(x: i32) -> Result<i32, String> {

if x == 0 {

Ok(42)

} else {

let y = g(x)?;

Ok(y)

}
+}

+fn g(x: i32) -> MyResult<i32, String> {

let _y = f(x)?;

it terminates with the given input, I don't care too much about it being a
sensible program

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rust/pull/33389/files/0de7b23ac739307c71249116d106c5d074f30b23#r62111982

The best kind of termination!

Thanks, this is fixed now.

huonw · 2016-05-09T23:06:16Z

src/libcore/ops.rs

+        where T: Carrier<Success=U, Error=V>
+    {
+        match self {
+            Ok(u) => T::from_success(u.into()),


It seems to me that these intos are useless: they're always "converting" from U to U, and V to V. Maybe the signature of translate wants to be something like:

fn translate<T>(self) where T: Carrier<Success = Self::Success>, Self::Error: Into<T::Error>,

(The thinking being converting the main value implicitly is not nearly as desirable as converting the error one.)

I think the signature is OK, but the intos shouldn't be there. I started with a more flexible approach, but decided it wasn't necessary. I think the intos are left over from that. Not really sure why it even compiles.

Makes sense.

Not really sure why it even compiles.

T: Into<T> for all (sized) T:

rust/src/libcore/convert.rs

Lines 231 to 243 in 0e7cb8b

// From implies Into

#[stable(feature = "rust1", since = "1.0.0")]

impl<T, U> Into<U> for T where U: From<T> {

fn into(self) -> U {

U::from(self)

}

}

// From (and thus Into) is reflexive

#[stable(feature = "rust1", since = "1.0.0")]

impl<T> From<T> for T {

fn from(t: T) -> T { t }

}

bors · 2016-05-10T06:52:32Z

☔ The latest upstream changes (presumably #33443) made this pull request unmergeable. Please resolve the merge conflicts.

glaebhoerl · 2016-05-10T07:43:51Z

FWIW newer versions of the RFC called this ResultCarrier which is a bit less jargony. Cool to see it implemented!

nikomatsakis · 2016-05-13T04:41:57Z

Crater run results: https://gist.github.com/nikomatsakis/eff9c3cb0d79e95b073283369ab37b01

4702 crates tested: 2948 working / 1358 broken / 1 regressed / 0 fixed / 395 unknown.

nikomatsakis · 2016-05-13T04:42:32Z

The 1 regression appears to be a timeout (false positive).

nrc · 2016-05-18T02:26:55Z

The language team decided that we should accept this PR, on the understanding that it is for experimentation and will have a period of discussion and examination before FCP. This discuss thread has more details.

Allows use with `Option` and custom `Result`-like types.

nrc · 2016-05-18T05:04:47Z

ping @alexcrichton see comment above from the lang team, also rebased.

diwic · 2016-05-18T11:55:13Z

This does not seem to change Into handling? I would have expected the into-part to move into the trait implementation somehow so it would be possible for a struct implementing Carrier to opt in (or opt out) from the into stuff.

Otherwise, +1 :-) I hope this goes in.

diwic · 2016-05-18T12:01:28Z

src/libcore/ops.rs

+    /// The type of the value when computation succeeds.
+    type Success;
+    /// The type of the value when computation errors out.
+    type Error;


Perhaps EarlyReturn could be a better name than Error, as it more closely resembles what actually happens? Returning early does not have to be an error.

bors · 2016-05-18T12:06:06Z

☔ The latest upstream changes (presumably #33654) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2016-05-18T16:30:17Z

r? @aturon

We discussed this in libs a day or so ago and @aturon is gonna write up our conclusions here

aturon · 2016-05-18T17:41:08Z

Sorry for the delayed writeup.

The libs team also talked about this PR, and a number of team members felt uncomfortable merging based on the accepted RFC, strongly preferring to amend the RFC with an explicit route for experimentation, especially given the contentious nature of the original RFC.

Personally, I can see arguments on both sides, and I think the high-order bit here is that the broader community needs some clear opportunity to weigh in -- whether via an RFC amendment or the new discuss threads.

Given that the two teams reached different conclusions, I propose escalating this decision to the core team, and am tagging accordingly. We'll be meeting today.

aturon · 2016-05-23T00:12:24Z

We discussed the situation in the core team meeting, and the TL;DR is that we believe an amendment RFC needs to happen before this PR is landed. While not everyone agreed that it was strictly necessary, it is the conservative choice, which seems prudent given how contentious the original RFC was. (Sorry @nrc!)

The core issue is that the original RFC did not lay out specific plans for expansion here, and while the lang team did say that we would "revisit" the question prior to stabilization, there were no details about that process. Those opposed to this generalization did not push hard on that point in the original RFC because it was taken off the table. And at least some people don't consider this generalization to be something that needs experimental evidence to decide, but rather is a question of mental model for the feature.

In the future, any "planned expansions" should be clearly laid out in the RFC and made part of the tracking issue.

It's unclear whether the amendment RFC should await some consensus on the discuss thread, or should be started now to drive traffic in that direction. I'll cross-post there for the time being.

alexcrichton · 2016-07-19T04:12:37Z

@nrc ping (just cleaning out some old PRs)

Should we close this for now?

nrc · 2016-07-19T22:23:52Z

Yeah, I guess so, we're not going to merge it without an RFC, so may as well close in the meantime

rust-highfive assigned alexcrichton May 3, 2016

nrc force-pushed the carrier branch from 691c688 to bb8e59e Compare May 3, 2016 20:51

jimmycuadra reviewed May 3, 2016
View reviewed changes

nrc force-pushed the carrier branch from bb8e59e to 0de7b23 Compare May 3, 2016 23:51

alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 4, 2016

durka reviewed May 4, 2016
View reviewed changes

nrc force-pushed the carrier branch 2 times, most recently from e89b9e4 to 79a1f5c Compare May 4, 2016 22:09

huonw reviewed May 9, 2016
View reviewed changes

nrc added T-lang Relevant to the language team, which will review and decide on the PR/issue. I-nominated S-waiting-on-crater Status: Waiting on a crater run to be completed. labels May 10, 2016

nrc force-pushed the carrier branch from 79a1f5c to 937f024 Compare May 10, 2016 05:59

nrc removed I-nominated S-waiting-on-crater Status: Waiting on a crater run to be completed. labels May 18, 2016

This was referenced May 18, 2016

Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436

Open

First-class error handling with ? and catch rust-lang/rfcs#243

Merged

nrc force-pushed the carrier branch from 937f024 to f9ff8d3 Compare May 18, 2016 05:03

Use a Carrier trait with the ? operator

f9ff8d3

Allows use with `Option` and custom `Result`-like types.

diwic reviewed May 18, 2016
View reviewed changes

rust-highfive assigned aturon and unassigned alexcrichton May 18, 2016

aturon added the T-core Relevant to the core team, which will review and decide on the PR/issue. label May 18, 2016

nrc closed this Jul 19, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use a Carrier trait with the `?` operator #33389

Use a Carrier trait with the `?` operator #33389

nrc commented May 3, 2016

rust-highfive commented May 3, 2016

durka commented May 3, 2016

jimmycuadra May 3, 2016

durka May 4, 2016

nrc May 4, 2016

durka May 4, 2016

nrc May 4, 2016

huonw May 9, 2016

nrc May 10, 2016

huonw May 10, 2016

bors commented May 10, 2016

glaebhoerl commented May 10, 2016

nikomatsakis commented May 13, 2016

nikomatsakis commented May 13, 2016

nrc commented May 18, 2016

nrc commented May 18, 2016

diwic commented May 18, 2016

diwic May 18, 2016

bors commented May 18, 2016

alexcrichton commented May 18, 2016

aturon commented May 18, 2016

aturon commented May 23, 2016

alexcrichton commented Jul 19, 2016

nrc commented Jul 19, 2016

	// From implies Into
	#[stable(feature = "rust1", since = "1.0.0")]
	impl<T, U> Into<U> for T where U: From<T> {
	fn into(self) -> U {
	U::from(self)
	}
	}

	// From (and thus Into) is reflexive
	#[stable(feature = "rust1", since = "1.0.0")]
	impl<T> From<T> for T {
	fn from(t: T) -> T { t }
	}

Use a Carrier trait with the ? operator #33389

Use a Carrier trait with the ? operator #33389

Conversation

nrc commented May 3, 2016

rust-highfive commented May 3, 2016

durka commented May 3, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented May 10, 2016

glaebhoerl commented May 10, 2016

nikomatsakis commented May 13, 2016

nikomatsakis commented May 13, 2016

nrc commented May 18, 2016

nrc commented May 18, 2016

diwic commented May 18, 2016

Choose a reason for hiding this comment

bors commented May 18, 2016

alexcrichton commented May 18, 2016

aturon commented May 18, 2016

aturon commented May 23, 2016

alexcrichton commented Jul 19, 2016

nrc commented Jul 19, 2016

Use a Carrier trait with the `?` operator #33389

Use a Carrier trait with the `?` operator #33389