Longer question marks RFC

[est31]

Rendered.

[kennytm]

I don't know why we must be restricted to [?!]+ 😄. In my Swift project I used the symbol ^ to perform something similar to Rust's ?.

postfix operator ^ {}
postfix func ^<T>(opt: T?) throws -> T { ... }
...
let address = try IPAddress(string: addresses[id]^)^.withPort(12345)

[durka]

Seems pointless. If we were to add "method macros" then expr? would change to expr.try!() and you could define other macros like expr.foo!(bar, baz). This RFC seems to churn the syntax (and unecessarily re-open a highly pressurized can of worms) without actually adding extensibility.

[est31]

@durka how should method macros work together with the catch keyword that the RFC has suggested as well? To "throw" towards the next catch, extra syntax is needed. The ? has served as that extra syntax before.

[ahicks92]

Going to join in the bikeshedding. Why not get rid of the operator and make it maybe <expr> or try <expr>?

The biggest problem with try! in my book is that it introduces extra parens, but I'm fine with a longer identifier for this sort of thing personally. I don't exactly see the problem with ?, not outside stupid screen reader bugs and limitations land, but if we want to change it I'm more than happy to suggest something that I would find more friendly to read for the hell of it.

I feel like alternative syntaxes were probably already bikeshedded on the original RFC, though. Has anyone checked that thread?

Method macros are interesting and, while off topic, please, yes, let's do that. I think the big problem with macros generally (at least, why I don't just use them) is that you can't namespace them, and it's going to be a long, long time before that's fixed. The current system makes it too expensive to use the convenient names; you can effectively only use it once per project or, if the crate is popular, once for the entire ecosystem.

Being able to make custom operators in Rust would also be a nice feature in limited circumstances, but probably you need to combine that with method macros to extend error handling.

[durka]

@est31 actually something like catch can be implemented as a macro, but it's horrifying.

@camlorn one of the big arguments in favor of ? is that things like try!(try!(try!(foo).bar()).baz()) turn into foo?.bar()?.baz()?, and try (try (try foo).bar()).baz() (or any other prefix keyword) is no better. Is there any difference when using a screenreader? I think that the postfix notation is much better for reading forwards, though it is harder to look at a single ? and figure out what it applies to (you have to parse the expression backwards, in effect), but I guess editors can help with that.

Also I think Rust has explicitly rejected custom operators as a design decision, we don't want to be Swift or Haskell.

[comex]

Longer question marks, eh? How about ？ FULLWIDTH QUESTION MARK? There's also the emoji version,❓. Nice and red!

[ahicks92]

@durka
I did say limited circumstances.

That said, it may not matter. I think, if you're willing to use words, you can have any custom operator you want inside something like a context! macro. I think you can even have precedence, though you can't get precedence above the built-in ones that I can figure.

And, with that scary thought, I'll avoid taking this further off topic.

[est31]

@camlorn

I think the big problem with macros generally (at least, why I don't just use them) is that you can't namespace them

That's wrong. Macros are always namespaced to the block they are defined. If you define a macro in mod.rs and want to use it in lib.rs that includes mod.rs, you will get an error. If you define a macro inside a crate, users of that crate won't get it unless you add #[macro_use] when using the crate. You can define macros inside methods, and they don't leak to outside scope.

What you think about is C/C++ preprocessor macros, which do act on a global scope and leak through headers per default until they are undefined, but which destroys any macros with the same name that were used before. Yes, you can't rename Rust makros (unlike with use ... as notation that works for all other language items), and if you use a crate's macros, you need to use all of them, but generally the situation is much much better than on say C/C++.

But your dislike against macros is symptomatic, and the unpopularity is listed as one of the drawbacks of a macro based solution to the problem in the RFC, although I personally would even prefer to use macros over custom operators in my code.

[est31]

@durka if you make an RFC for adding method macros and removing the ? operator, I would really welcome it and would close this RFC in favour of yours considering that mine has so many negative votes already (although nobody from the core team has commented yet, so I don't know their thoughts yet). Let's discuss the idea in its own thread.

@camlorn

I feel like alternative syntaxes were probably already bikeshedded on the original RFC, though. Has anyone checked that thread?

I've skimmed over it before doing the RFC, but most of the discussion was about entirely different approaches, like one can observe in this thread already. Almost none was about which notation exactly should be used.

To get discussion on topic again: What criticism is there to this proposal other than "I think RFC 243 was wrong, and this is basically RFC 243, lets use [...] instead, I'm against this RFC"?

Why do you think the ? operator suits better than the ?! operator? Do you want it to stay short?

[durka]

Why do you think the ? operator suits better than the ?! operator? Do you want it to stay short?

Everything starts at -100 points. The ?/catch RFC already climbed out of that hole (it took several years). So it seems like a misdirection to present ?! and say "OK, what are the downsides?". Rather, what are the upsides of switching from ? to ?!? I see two potential reasons to move away from ? (did I miss any?):

1. It's too short (easy to miss when reading code).
2. It doesn't generalize (we might want a postfix modifier that does something else).

(Also a note that some people consider (1) a positive, because often when reading code you want to focus on the main flow and worry about error handling later.)

This RFC would solve (1) (sort of -- two characters really isn't much more than one) but doesn't touch (2) at all. That's why I don't see it as a major gain.

if you make an RFC for adding method macros and removing the ? operator, I would really welcome it

I'm not even sure they are a good idea, so I probably won't be the one to write that RFC. We'll see what happens when Macros 2.0 shakes out, maybe.

[ahicks92]

@est31
My dislike of macros is not symptomatic of C++, and I'm not wrong. From the perspective of a public interface, they are unnamespaced. This means that the list of good names that don't start with mycrate_ is valuable and finite.

I could say more, but this is off topic. Suffice it to say that the lack of namespacing support for macros frustrates me greatly, especially since we don't have default and keyword parameters and you have to use macros to emulate them.

[comex]

@camlorn It is off topic, but allowing macros to be namespaced and imported like other items is planned for macros 2.0.

[whitequark]

How about renaming it to ‽ ? We could also have a right-associative version, ⸘.

[rustonaut]

@durka, is there a "methode macro" RFC??

I think such a think wouldn't be to bad e.g. expr? would first become expr.try!() but that woudln't work with catch {...} but then you could "upgrade" try like in the current ? RFC to work with catch and to make sure it is clear separated to "normal" method macros you could again rename it to ? which means catch { foo?.bar()?.baz()? } would become catch { foo.?!().bar().?!().baz.?!() }.
Hm, which I just noticed is not very readable. And if you ad more special cases for a "methode macro" try/? then you would and with catch { foo.?.bar().?.baz.? } or catch { foo.?().bar().?().baz.?() } which is where we started.
So why not keep ? and maybe if there is a "methode macro' RFC and it gets accepted define ? as a (very) special case of it... (so is there such an (pre)RFC?).

[keeperofdakeys]

I haven't seen any full proposal on implementing method macros, just a vague idea being thrown around. There has been some other discussion about it in rust-lang/rust#31436.

[kennytm]

@dathinab There is an issue #676, no pre-RFCs yet.

Making ? to be an identifier would require another RFC besides method-macro.

[Mark-Simulacrum]

From the linked issue discussion on method macros:

From nrc:

Just to note that I hate the idea of method macros and I can't think of a language feature I would oppose more strongly. They fuzz the phasing of the compiler, and unless we make really quite fundamental changes to the language there is no way they can exist and have unsurprising behaviour. They are also hard to parse sensibly and almost certainly not backwards compatible.

And a similar note from withoutboats.

[nikomatsakis]

Overall, I'm pretty happy with ? and not inclined to change it to anything.

That said: ?! in particular has a "WTF" connotation to it that, while humorous, doesn't really seem suitable. (I can't tell if this is intentional?)

[est31]

No, the "WTF" connotation is not intentional.

My main concern is that ? is too short and can be overlooked too easily. Of course, its always a tradeoff between readability of the "normal" control flow and readability of the "return early" control flow, but I like the length of try!, and ? alone makes the situation worse imo.

Any other ideas how a longer version of ? could look like? Yes, method macros would use try!, but the name shouldn't be used imo when its a hardcoded operator. It would lead to confusion that the prefix try! is a macro and the postfix try! is an operator.

[Mark-Simulacrum]

I think that a good reason for why "?" is significant enough is that I expect editors to change syntax highlighting to highlight it specially, and from what I can tell that should be good enough. @durka seems to share this belief.

As it relates to the RFC, ?! does not feel like much of an improvement over ? since it isn't significantly longer. I also believe that try! should be used for those cases where error handling is intended to be explicit; perhaps wrapping a chain of ?-linked method calls.

[sciyoshi]

I really like the current ? operator (which mimics CoffeeScript's), but I also like the possibility of keeping it reserved for nullable types (u32? vs Option<u32>).

[est31]

Note that it wouldn't be the first time to rename something during or close to stabilisation: rust-lang/rust#27719 (comment)

[aturon]

I think this would be better served by discussion on the tracking issue for ?. We often make bikeshed-level decisions there.

FWIW, I also think it's very unlikely that this change will be accepted, since it cuts against much of the spirit of the ? proposal. If we collectively believe that readability of ? is a problem, we're likelier to stay with try! in some form, I suspect.

I'm going to close this RFC for the time being, in favor of tracking issue discussion.

[est31]

since it cuts against much of the spirit of the ? proposal

Wait, wasn't the main argument for ? that it allows chaining? I mean the brevity was mostly a side effect no?

Still doesn't change my opinion that ? is too long and whose usage can in fact be dangerous, but seems this RFC won't be merged. ? is still miles better than what other languages have, which is no sign of "stuff can early return here" at all.

[ticki]

@est31 Eh, ? isn't for chaining, it's for propagation. ? is equivalent to try! in an extended form, and not and_then.

[est31]

@ticki yes, I know that it is not and_then. The hidden early return is in fact part of the reason why i think ? is too short.

With chaining I mean the use case outlined in this comment #243 (comment) , aka builder pattern.