Automatic "?" inside try {...} blocks

[SheepKey]

Ok, thank you for furthering the discussion. You are making some good points.

So the real question is why the downsides of non-locality are fine in cases like RAII or panics or asserts

RAII: I explained my view. Rust is fundamentally a RAII language. It is part of the ownership model and the fundamental way that resources are managed. It is universally expected throughout all Rust code. It is never surprising and always trivial to reason about.

Unlike RAII, which is consistent and expected everywhere, implicit ? makes the semantics inconsistent and confusing.

Panics and asserts: these are intended as a way to catch bugs. They should only happen on catastrophic failure where the most sensible thing to do is abort the program, because a bug has been hit (like some invariant being violated) and it is unclear how the program could proceed from there. They should not occur as part of the normal execution of a program. This justifies their non-locality. They are a way for the program to commit suicide in a controlled way, in situations where there is nothing better that can be done. At least that is the intention; of course these features can be misused in various ways, but that is what conventions are for.

To be perfectly clear: I do think we probably should keep ?. … …

Yeah, I understand you :). It is great to argue for the opposite side from your personal beliefs. It helps consider all sides better and see different arguments.

especially in the face of potential benefits like try-polymorphism.

In the name of considering arguments for the opposite side … I feel like I haven’t considered the benefits of implicit ? well enough. It seemed like such a clear-cut no-no. I will look at try-polymorphism in more detail and educate myself. Right now I don’t have any valuable comments on it.

I certainly agree that early-exit is something to be wary about- I’ve said so several times in this thread. But that doesn’t make it non-trivial- it only makes it non-local, and only in a very simple and straightforward way.

Silently converting types and hiding things that can fail are also big problems. So far, we have seen at least 3 major problems with the implicit ? proposal. I feel like that is too much. Individually, these considerations might be fairly “trivial”, but together, they introduce a lot of things that you have to be careful about. Since Rust’s philosophy is to enable fearless programming without footguns/pitfalls as much as possible, anything like this that introduces such extra reasoning overhead goes against Rust’s goals. I don’t want to write in a language where I have to constantly worry about missing something that could go wrong. If I did, I’d be writing C/C++. This is possibly the single main reason why I love Rust and I’d hate it if new features were introduced that go against that. I love that Rust makes everything I need to consider about the correctness of my code obvious from the syntax and semantics of the language and enforces that I deal with all of it.

implicit await/async stuff

OK, I will admit that I perhaps should not have commented on this. I have almost no experience with writing async code and there are many people in this community with far more valid opinions, based on actual experience, to drive those discussions and make decisions about the best trade-offs. I don’t really understand the implications. Now I feel like my view was misled, as I did not realise the 2-sided nature of the tradeoffs involved.

However, your post was insightful. Thank you! I learned new things.

[Centril]

Type inference: again, trivial to reason about.

Honestly; I’ve often found that type inference is anything but trivial to reason about in some cases. Sure, you could write out the types if you wanted to; but when a whole lot of things are being inferred together and when I am writing something in a generic context, I have to rely on really good naming of functions for the semantics to be clear enough.

I don’t think it is as easy as you portray things to be.

[SheepKey]

Fair enough. I guess people’s experiences vary and im biased towards my experiences.

I tend to follow the intention rather than the technicalities.

The intention behind type inference is to make code clearer when the types are obvious, allowing you to omit redundant information. That’s how I use it. If the types are obvious to me (and it feels redundant to write them down) and the compiler can infer them, I will omit them. If the code feels clearer to read with them written in, even if the compiler can infer them, I will write them out.

Yeah, I can see how someone who has different habits from me would have a different experience. If you don’t actively think about what is most clear and readable, but rather you always omit types unless the compiler complains and only add them in to make the code compile, then yeah I can see how you would be omitting types in many confusing places.

This brings up a great point that I don’t often see discussed enough. People usually tend to argue about new features mostly on technical merits. It would be great to also give more consideration to how those features fit with different people’s coding mindset and habits.

Edit: more clear examples (things that should be given some thought when evaluating a new feature):

• how would a lazy person who just writes the minimal code to get things to work use the feature?
• how would it affect the experience for a person who likes to copypaste code examples (from books/tutorials/stackoverflow/etc) and hack them until they work?
• how would it be used by a perfectionist who focuses on the pure elegance of their code?
• many others that i am missing

[MajorBreakfast]

I have to rely on really good naming of functions for the semantics to be clear enough.

Or well named variables. Let’s not forget that we often read code that others have written. We know that it works. We just need to be able to follow what’s happening. Type inference helps with keeping the “noise” down, so that we can see what the code is doing. Yes we’re hiding information. But, it’s a trade-off that I’d make any day.

Edit: And let’s not forget that Rust forces us to spell out function signatures. Type inference mostly only hides redundant stuff.

[Ixrec]

This brings up a great point that I don’t often see discussed enough. People usually tend to argue about new features mostly on technical merits. It would be great to also give more consideration to how those features fit with different people’s coding mindset and habits.

Oh this happens all the time. The reason why technical arguments might seem more prominent is that technical arguments are more objective, and once raised tend to be impossible to disagree with. Arguments based on a particular “coding mindset” tend to be not only subjective, but impossible to form a consensus on. Other people have a different mindset, neither is “right” or “wrong”, there aren’t any arguments that would make someone “change sides”, and there’s no way to acquire convincing evidence that either is so much more popular that it should dictate a feature’s design. (e.g., I think there’s a lot of this going on with try/throw/catch discussions recently)

But more useful non-technical questions like:

• how would a lazy person who just writes the minimal code to get things to work use the feature?
• how would it affect the experience for a person who likes to copypaste code examples (from books/tutorials/stackoverflow/etc) and hack them until they work?
• how would it be used by a perfectionist who focuses on the pure elegance of their code?

do get raised in RFC discussions all the time, when the subject is broad enough for this to matter. If you look at some of the module reform RFCs and internals threads from last year you’ll see dozens upon dozens of arguments getting made based on exactly these questions, some of which became major design goals in the final proposal (e.g., preventing “path confusion”, where paths that are valid in the root module are invalid in any other module, because that specific inconsistency was a tremendous stumbling block for… well not even just newbies, it confused everyone).

[steven099]

I believe this would just be BAD™. As I previously argued in other threads, I felt it a mistake for Rust to adopt try/catch terminology for it’s error handling as it would encourage endless bike-shedding on making it work more like traditional try…catch…finally in other languages. This thread seems to be an example of that. Hard Down-Vote.

Maybe. I feel like there was always going to be bikeshedding on it. However, I think the design decision more immediately responsible for this suggestion is renaming catch { ... } to try { ... }. The motivation here was that try { try_something()? } seems redundant:

In the case of code within try{…} blocks, I wondered why the need for ? was retained because it seems redundant and a bit of a wart left behind from the process of evolution.

And there is actually a point here. The reason people wanted catch renamed to try was because, in languages with try { ... } catch { ... }, the fallible code goes in the try block, so if you think of try/catch { ... } as a block with fallible code in it, it makes more sense to call it ‘try’. However, this is based on a superficial parallel! In languages with try { ... } catch { ... }, try { ... } on its own (if it’s permitted) doesn’t actually catch errors; it serves solely to mark code that can fail, the role served by ? in Rust. So of course someone would come along later and think that try { try_something()? } is redundant. By naming it try { ... }, we’ve hidden the fact that it’s actually a catch operation—completely orthogonal to ?—and given it a name which suggests it does the same thing as ?.

[Ixrec]

The reason people wanted catch renamed to try was because, in languages with try { ... } catch { ... } , the fallible code goes in the try block

Eh, no, that’s not the only reason, or even the main reason. In fact I think it’d be doing all sides of the debate a disservice to claim there is any single main reason, so I’m just going to link the comment where @scottmcm summarized all the arguments (afaik no new arguments have surfaced in the past month): https://github.com/rust-lang/rfcs/pull/2388#issuecomment-381059548

[steven099]

Eh, no, that’s not the only reason, or even the main reason. In fact I think it’d be doing all sides of the debate a disservice to claim there is any single main reason, so I’m just going to link the comment where @scottmcm summaries all the arguments (which I’m pretty sure have not changed in the past month)

This point:

It allows us to leverage peoples’ intuitions from other languages

which is the most developed, mostly deals with exactly what I was talking about: mapping the Rust feature to try { ... } blocks in other languages as the basis for people to form intuitions. And I’m pointing out here that this is a case where that intuition is misleading, which I think challenges the assertion that people’s intuitions about try { ... } are more useful than they would be for catch { ... }.

Edit: It could turn out on balance that try { ... } does encourage better intuitions. However, reasoning about what intuitions people will form is hard, and finding evidence to support that reasoning can be even harder. I think this thread is interesting just because its an actual tangible piece of evidence on the question. Obviously, you can’t extrapolate from one data point, and getting evidence in support of try { ... } is going to be harder now that people won’t be trying to form an intuition about catch { ... }. You could argue that the reason people pushed for try { ... } in the first place was because they weren’t getting the right intuition for catch, but this is iffy because you could also say that this is a preference formed after reaching a correct intuition based on catch which has no bearing on whether one syntax is more intuitive than the other.

[SheepKey]

OK, it is great that is being discussed!

I guess the fault is with me for not following those discussions , which gave me that impression.

Many RFC discussions tend to get really really long and I don’t have the time or the attention span to read the whole thing. Also most of the info near the beginning of the thread quickly becomes irrelevant as it gets shot down later in the discussion. There is no easy way to start reading, since you don’t know if the information early on is important or not until you read the replies later on (which you can’t always understand if you haven’t read the earlier info, so a circular dependency ).

It would be great if these discussions could somehow be made more accessible to people who haven’t been there from the beginning, without reading the whole thing. Perhaps with periodic “checkpoint posts” that summarise and reiterate the state of the discussion, so that one could start reading from there onwards and ignore everything prior? I’ve seen a few of the recent big discussions (async/await library support, try blocks) have at least one “checkpoint post” like this and I think it is good practice! It should happen more!

That said, this got quite off-topic at this point. (but then, this whole thread seems to be very off-topic at this stage…)

[MajorBreakfast]

It would be great if these discussions could somehow be made more accessible to people who haven’t been there from the beginning, without reading the whole thing

@aturon did something like that in the async/await RFC: He marked comments as “outdated” after they became irrelevant.

---

Edit: I really like the renaming to “try”. The fallible code goes into the try block - just like in most other programming languages. Makes sense to me.

[SheepKey]

Yeah that is another great thing to do!

I just wanted to share that I really appreciate such efforts and encourage it to happen more! It really helps.

[Centril]

Edit: And let’s not forget that Rust forces us to spell out function signatures. Type inference mostly only hides redundant stuff.

Right. With function-local inference (what Rust has), the degree to which type inference is legible is proportional (to some extent) to the length of a function. The longer it is, the more it will start to feel like global type inference (which Haskell has, but Rust doesn’t).

In Haskell, I typically use global type inference as a development tool where 1) I define a function (without type signature, unless I’m sure of what it will be…), 2) ask the REPL what the type of the function is, 3) take the type from the REPL and paste it as the signature, 4) start over at 1). I only keep one function globally inferred at a time. All functions I commit to VCS have their type signatures there explicitly. I also tend to write very small functions.

Or well named variables.

As a serial eta-reducer (who likes the point-free, or “point-less” according to some, style), I try to avoid let bindings

[steven099]

Edit: I really like the renaming to “try”. The fallible code goes into the try block

…or outside the try block. The only consistent marker of where fallible code can be is ?. The only thing try { ... } is doing here is preventing errors from propagating to the function boundary, something that try { ... } doesn’t do on its own in other languages.

Anyways, I can understand why people who already understand the feature might prefer ‘try’, I’m just not sure if this preference has any bearing on the relative intuitiveness of the two choices. I guess we’ll find out based on how often people think that try makes ? redundant.

[gbutler]

I guess we’ll find out based on how often people think that try makes ? redundant.

My prediction is that it will be endlessly brought up by people new to the language. They will constantly wonder why “try { … }” doesn’t work like other language and they will constant insist that Rust has a broken/deficient implementation of exception handling and try…catch…finally (instead of understanding what Rust error handling really is) and constantly insist that it needs to be fixed in the next edition.

[steven099]

To be fair, the only way to avoid this completely might be to have try…catch…finally . If the goal is not to have try…catch…finally because we think Rust can offer a better model, then this might just be an inevitability.

Edit: See below.

[scottmcm]

might be to have try…catch…finally

Note that C++ doesn’t have finally, since it has RAII, so I think it’s good and consistent for Rust to also not have it, for the same reason.

[MajorBreakfast]

Anyways, I can understand why people who already understand the feature might prefer ‘ try ’, I’m just not sure if this preference has any bearing on the relative intuitiveness of the two choices

Everything you say is spot on. However, I stand by my assessment that it’s best to stick with existing conventions from other programming languages whenever it makes sense. That’s IMO also a form of intuitiveness. catch would be a good name choice if Rust existed in a vacuum. However, other languages have something similar and almost all call it try {}. Also, many use catch {} to wrap the error handling code. Deviating from these established meanings would only confuse people coming from other programming languages (i.e. confuse almost everybody). Familiarity is probably also the reason why enum was picked as keyword for a feature that is technically a “tagged union” not an “enum”. Not the same, but close enough.

[steven099]

However, I stand by my assessment that it’s best to stick with existing conventions from other programming languages whenever it makes sense.

I very much agree with this.

However, other languages have something similar and almost all call it try .

I just disagree with this . I would argue that languages with try ... catch would call what try { ... } does in Rust “catching”. The error handling code is referred to as “catch handlers”, or “handling”.

Musings on Rust's design

It's interesting to think about the effect of Rust's design on the nature of error handling. There are two things catch handlers have to do in other languages to allow a fallible operation to converge (as opposed to diverging by throwing, returning, aborting, etc...) and allow execution to continue with the following statement: (1) ensure any variables that will be subsequently used are initialized, and (2) manipulate the state of the program to meet any post-conditions of the statement. In Rust, initialization tracking means that variables just won't be usable unless you ensure they are invariantly initialized. Also, since Rust is expression oriented, the post-condition an expression needs to meet to allow it to converge is to produce a value that matches its type. If the type of a fallible operation can represent both the success and failure cases, then no further work is needed to allow it to converge, so no catch handlers are needed.

[MajorBreakfast]

I just disagree with this . I would argue that languages with try ... catch would call what try { ... } does in Rust “catching”.

Sure. Makes sense to call it “catching”. To clarify: With try I was talking about a try {} block, not about “to try”. I’ve edited my post and added curly braces to make it unambiguous.

[notriddle]

This topic was automatically closed after 6 days. New replies are no longer allowed.