The ? operator will be harmful to Rust

[comex]

I think your argument can be separated into two distinct points:

1. Rust’s ? is confusing because it works differently from similar syntax in other languages.

2. Rust’s ? is confusing because hiding returns in the middle of expressions is inherently confusing.

Both points are valid, but I have counterpoints to each:

1. Today, safe navigation using ?. is far from ubiquitously known. Ruby’s safe navigation operator is new and uses a different symbol; C#'s safe navigation operator is only a year old or so; Swift itself is two years old; and none of Groovy, Kotlin and Perl 6 have particularly wide adoption. (However, as time passes, knowledge of ?.-as-safe-navigation is likely to spread more than that of Rust’s version.)

   Also relevant to familiarity: Rust’s ? has a fairly close analogue in Swift, it just uses different syntax, try foo() vs. foo()?.

2. It’s worth noting that 5 of the 6 languages you mentioned, as well as many other languages people might be moving to Rust from, have non-checked exceptions, so every function call can be an implicit return.

[wycats]

It’s worth noting that 5 of the 6 languages you mentioned, as well as many other languages people might be moving to Rust from, have non-checked exceptions, so every function call can be an implicit return.

Indeed. The ? operator in Rust indicates the handful of places that can produce implicit returns by making those returns explicit in the language and manually propagated.

For example, if you look at the spec for JavaScript, most operations produce a completion (which can either be a “normal” completion or a “throw” completion).

The spec has a macro called ReturnIfAbrupt:

Algorithms steps that say

1. ReturnIfAbrupt(argument).

mean the same thing as:

1. If argument is an abrupt completion, return argument.
2. Else if argument is a Completion Record, let argument be argument.[[value]].

Recent versions of the JavaScript spec have added a ? prefix operator:

Abstract operations referenced using the functional application style
and the method application style that are prefixed by `?` indicate that
ReturnIfAbrupt should be applied to the resulting Completion Record.

Yes, Completion Record is basically Result, and ReturnIfAbrupt is basically try!.

In other words, virtually all operations in JavaScript produce Result, and the language semantics add ? to every expression to propagate errors. In Rust, since many fewer expressions can produce errors, the explicitness makes it easy to handle errors robustly.

[kennytm]

• Ruby uses &. because name? is an identifier. If Rust did not use name! for macros we could use ! instead, although this could also be confusing since in Swift it means .unwrap().

• RFC 204 and 243 are “only 2 years old”. I don’t think that a syntax being relatively new is a good counterpoint.

[wycats]

Ruby uses &. because name? is an identifier

Maybe so, but the mnemonic with && short-circuiting is great and I’m happy Ruby ended up with &.. In any event, it means the syntax isn’t universal (additionally, Perl 6 uses .?, which more strongly indicates a separate token vs. a suffix operator).

[wycats]

Having worked in many other languages, I was completely confused by ? being used for try! instead of option.

Out of curiosity, what would it mean to be used for option?

[mcpherrinm]

Comex summarized my concerns quite well. I am almost entirely concerned about the first point in that summary, rather than the second.

I don’t buy the argument that the syntax is fine because the ?. operator is relatively unknown. If we want Rust to be a language that lasts more than the next few years, that won’t stay true. Rust’s ? operator will surely be even less well known, and by differing from the PL community norms, the language will forever have different behaviour from its peers. That adds cognitive load.

[kennytm]

Recent versions of the JavaScript spec have added a ? prefix operator:

The prefix ? is only a convention used to describe the algorithms, alongside the prefix ! (meaning .unwrap()) (e.g. https://tc39.github.io/ecma262/#sec-array-exotic-objects-defineownproperty-p-desc). These are not part of real JavaScript syntax.

[wycats]

The prefix ? is only a convention used to describe the algorithms, alongside the prefix ! (meaning .unwrap())

Right. The use from the spec was just an illustration of comex’s comment:

It’s worth noting that 5 of the 6 languages you mentioned, as well as many other languages people might be moving to Rust from, have non-checked exceptions, so every function call can be an implicit return.

The fact that the spec uses mechanisms that are almost identical to first-class constructs in Rust just shows that the symmetry is more or less exact.

[wycats]

Rust’s ? operator will surely be even less well known, and by differing from the PL community norms, the language will forever have different behaviour from its peers.

I’d think that the fact that Rust doesn’t have recoverable exceptions, in comparison to its peers, would be a much larger divergence than the meaning of the ? suffix operator (which can be used without a following ., as in let bytes = read()?).

Rust’s error story is probably going to end up being something that new Rust users need to understand pretty early on (along with the ownership story, and how to use Cargo), so I think the situation will be different over time than the way it feels when introduced as a new feature to existing Rust users.

[lifthrasiir]

By hiding return statements in the middle of expressions, I believe Rust control flow will be very surprising to casual users of basically every other programming language.

I have mentioned this in /r/rust, but did you mean that even try! is problematic? I believe the RFC didn’t discuss about the validness of early return itself on the ground that try! always has been existed. The view that non-local jumps including try!, nested break and even nested return are bad is valid, but is also clearly out of the RFC’s scope.

[Cyberax]

IMO, Rust should admit that the error handling right now is broken and just bite the bullet and design a good checked exception system, that can be implemented through SJLJ (set-jump-long-jump) exceptions with optional DWARF unwinding where possible.

All these special macros and operators are just adding more confusion. Especially since there’s a parallel unwinding system of panics.

Otherwise, perhaps this issue should just be postponed for some time until there’s a clear consensus of what should be done.

[pinbender]

Roughly, given an option a, a?.b() would be equivalent to a.map(|x| x.b()).

[leonardo]

IMO, Rust should admit that the error handling right now is broken and just bite the bullet and design a good checked exception system,

I think Rust error Handling is the work of genius And and I think it currently works sufficiently well for a system language.

[Uther]

In my opinion, the difference with other language it is not a big problem since a person who learns Rust should learn pretty early the ? syntax. And people who don’t know rust enough probably don’t need the detail when they read Rust code. They should be focused on the algorithm.

I don’t see the problem with the fact that ? can return early too : the sigil and the Result return type make this pretty explicit.

[nrc]

When the feature was first mooted I was in favour of ? doing something like proposed from other languages. But I think that the feature as implemented today is actually superior in that it matches what I want to do in most situations, and in situations where it is not what I want, then usually it is because my program is designed badly, after refactoring to appease the ? semantics I nearly always have much nicer code. Ideally, we would align with other languages, but here we can do better without doing something dramatically surprising. And, frankly, we are not talking about equals or dot here, ? is actually fairly uncommon in the wider PL world.

If you think in terms of implicit returns, you are approaching the code in the wrong way. As mentioned by others, the best way to think of ? is in terms of normal and exceptional control flow. If I am interested in reading the normal control flow for a function, I ignore the ? (which is pretty easy to do). If I want to read closer and investigate where a function could possibly return, then I have to look for ! (since macros can always return), ? (obviously), and for function calls that could panic. Of all these, searching for ? is the least annoying and even then I only have to do it if the function returns a Result. To me this a refinement of explicit exceptions, and done so in a more efficient way (both at runtime and in terms of ergonomics/syntax).

[birkenfeld]

Otherwise, perhaps this issue should just be postponed for some time until there’s a clear consensus of what should be done.

The RFC was discussed for a long time (it originated in 2014!) and accepted. That’s pretty much the definition of “clear consensus” in the Rust community.

There will always be those who dislike it, but that’s no different from many other language features/omissions that deviate from “common” expectations.

[Cyberax]

Back in 2014 Rust was still abusing sigils and had a runtime with green threads. Lots of time has passed since then.

Anyway, I just want to register my personal distaste for adding any hidden implicit functionality. Doubly so because it adds to the current confusing patchwork of disparate error handling techniques.

It’s also interesting that people are fighting against named arguments in a nearby thread on the grounds that it might introduce confusion. Even though the original proposals are mirroring the bog standard syntax present even in Ada and Fortran.

But here we have a truly non-standard and confusing operator that has very different semantic in other languages. Go figure…

[wycats]

Back in 2014 Rust was still abusing sigils and had a runtime with green threads

The RFC was merged this February and had literally hundreds of comments since 1.0, largely in the last few months leading up to the merge.

As @birkenfeld said, the RFC process, with all of those comments, is how we arrive at consensus for new features in the Rust community.

It’s fine to bring up issues later (before the feature has been finally un-gated), but there’s generally a high bar to clear (compelling new evidence that wasn’t discussed in the original RFC thread) to decide to reject an implemented feature that went through the RFC process and was vigorously debated until the arguments reached a steady state.

Anyway, I just want to register my personal distaste for adding any hidden implicit functionality

You may be worried that the ? is too easy to miss, but it’s not implicit. Exceptions are more implicit, because they create return points that are completely hidden from view. ? is an explicit way to propagate an error. It’s fewer characters than try!(expr), but it’s no less explicit.

[hauleth]

Main issue thet I see with ? operator is that this is diverging operator. I mean that it contains hidden return in middle of the function. I would rather see it as a pipeline operator that push down the error. It would be similar to and_then and that sugar would be nice and would play quite good with current ecosystem.

[wycats]

Main issue thet I see with ? operator is that this is diverging operator. I mean that it contains hidden return in middle of the function.

Do you have the same issue with try!?