#Rust2019 blog post: The Last Thing Rust Needs

[H2CO3]

a blanket “we don’t need convenience” statement.

And I’d like to see a more nuanced reading of my actual statement – it wasn’t “we don’t need convenience”. We do, the point is that they come with trade-offs which are not always apparent but should probably be taken more seriously.

depending on your perspective and which incarnation of it you’re talking about

So at best this is a bad example, but at worst your whole point is an unfortunate oversimplification

Depending on your perspective, you might disagree, but it doesn’t make it a bad example. It’s a perfectly fine example of a problem that exists, and it demonstrates my point.

It is also kind of unfair to attack my argument based on the idea that “if this feature were different, it would be more orthogonal and elegant”. Sure, basically any feature name could be arbitrarily reinterpreted to mean anything else, but there’s not much point in doing so. I’m feeling you are focusing too much on words here. Whether or not it’s called Ok-wrapping or something else is not my point; what I was criticizing in that specific example is the mechanism and method of special-casing yet another concrete type with the (primary or only) goal of removing a couple of characters to type. There has been such a proposal in the past; it might have been iterated, modified, renamed, or even withdrawn since I read about it last time, but my point (about its specific behavior at the point of time when I saw it) still stands.

[Centril]

special-casing yet another concrete type with the (primary or only) goal of removing a couple of characters to type

But that’s not what Ok-wrapping in the current implementation of try { .. } does; it also Some-wraps or Poll<T>-wraps.

There has been such a proposal in the past; it might have been iterated, modified, renamed, or even withdrawn since I read about it last time, but my point (about its specific behavior at the point of time when I saw it) still stands.

There have been many different Ok-wrapping proposals; some more elegant, some less, some more special cased, some not at all. Concretion would help advance this discussion.

[newpavlov]

what I was criticizing in that specific example is the mechanism and method of special-casing yet another concrete type with the (primary or only) goal of removing a couple of characters to type.

Using for instead of explicit loop { .. } is also can be seen as a “special-casing yet another concrete type with the (primary or only) goal of removing a couple of characters to type”. And do not forget that many Ok-wrapping proposals were defined in terms of Try trait, so you will be able to use this functionality for any custom type.

As a proponent of Ok-wrapping I believe that things like Ok(()), return Err(MyError) or Err(MyError)? are too common to deserve a special attention. Also I believe this feature is quite orthogonal to other language features and does not introduce any incoherences.

UPD: To be explicit I have in mind the following flavour of try fn/Ok-wrapping:

// Note that we still have to use `Result<(), MyError>` in signatures
try fn foo() -> Result<(), MyError> {
    if flag() { throw MyError }
    // no need for Ok(())
}
try fn bar() -> Result<u32, MyError> {
    foo()?;
    1
}

[H2CO3]

But that’s not what Ok -wrapping in the current implementation of try { .. } does

Excellent, then the relevant part of my criticism doesn’t apply to the current implementation.

[rpjohnst]

the point is that they come with trade-offs which are not always apparent but should probably be taken more seriously.

I don’t see how you can possibly make this claim while we’re simultaneously seeing blog posts about how RFCs get too much feedback. The trade-offs have high visibility and are taken very seriously.

Here’s a question for you- what would it take for you to see them as being taken “seriously enough?” Immediate termination of discussion around all features you dislike?

It is also kind of unfair to attack my argument based on the idea that “if this feature were different, it would be more orthogonal and elegant”.

This is absurd and not what anyone is doing. I’m talking about the primary, accepted form of Ok-wrapping, as explicitly opposed to the unfiltered, assorted musings found on i.r-l.o. I’m talking about the form that everyone calls “Ok-wrapping,” and that you yourself have discussed in the past. That is the version that I’m calling orthogonal and elegant.

[DrizztVD]

However, most of other problems have precise solutions: you don’t need AI to generate an impl from a trait, or to replace a match with an if-let, or to do a project-wide refactoring.

Sure, but think beyond that even. What about typing the program logic and the data structure get’s auto-inferred to a large extent? What if the refactoring can be automated to a large degree using similarities between other refactorings? The design space is massively underutilised imo, even after adding all the ‘simple’ autocompletion functionality.

[burntsushi]

I’m talking about the primary, accepted form of Ok -wrapping, as explicitly opposed to the unfiltered, assorted musings found on i.r-l.o. I’m talking about the form that everyone calls “ Ok -wrapping,” and that you yourself have discussed in the past. That is the version that I’m calling orthogonal and elegant.

I haven’t been following the Ok-wrapping conversations too closely personally. I certainly do not, off hand, know the differences between what the “accepted” form of Ok-wrapping is and what the assorted musings are.

Folks here might consider that not everyone is on the same page with respect to Ok-wrapping. As an example, from my perspective, when I hear, “Ok-wrapping,” I hear, “change the language semantics to implicitly insert Ok around values in certain circumstances.” I wouldn’t be surprised if 1) others perceived it the same way and 2) in that light, others might react negatively to the change. (I know I do.) I just did some searching, and I can’t seem to find something written down that describes what the “accepted” version of Ok-wrapping is. (I suspect I am not using the right keywords.) For example, I don’t see an RFC anywhere about it? I hope I didn’t miss it, because I’m certainly very interested in that addition and would like the opportunity to give feedback.

I’m not trying to get between you and @H2CO3 here, but just thought I’d share my perspective on what “Ok-wrapping” means to me.

[Nemo157]

The only accepted form of Ok-wrapping (to my knowledge) is what was originally accepted as part of the ? + catch block RFC: RFC243 § catch expressions. Since then "catch expressions" have been renamed to "try blocks" in RFC2388.

This is a very limited form of Ok-wrapping, only the implicit return value from a try block is wrapped into the success variant of the block’s return type.

---

While I do agree with some of the sentiment of the blog post, this example specifically I feel does reduce its impact somewhat. Especially this specific quote really annoyed me while reading it:

However, after a short period of getting used to, the (minor) pain associated with having to write an explicit Ok or return Err(...) quickly fades away.

I have been writing Rust as a hobby (and a very small bit of work) language for the last 4 years, and still every single time I have to write Ok(()) at the end of a small closure that does some IO I feel the readability pain. Maybe the pain has been numbed slightly by repeated infliction, but I really wouldn’t say it’s faded away.

[steveklabnik]

That second RFC says

// Note: OK-wrapping is assumed here, but it is not the goal of this RFC
// to decide either in favor or against OK-wrapping.

which seems a bit tenuous to me, I dunno.

[Nemo157]

The second RFC was just changing the keyword without affecting semantics, the original RFC specified Ok-wrapping, but also #41414 is linked from the tracking issue as the issue that resolved whether Ok-wrapping should happen or not.

[oooutlk]

I did tried to implement OK-Wrapping in Rust library during the development of CeX-0.3.0-alpha, which is a library to support throws in function signatures.

I think it is feasible to implement OK-Wrapping in library. But I did not finish my poc, which works for simple cases but need improved to be sound.

I stopped because I doubt if it is necessary. As I understand, OK-Wrapping will break some basic Rust syntax rules, which will lead to confusion.

1. The mismatch between returned value and the function return type in signature.

2. The mismatched type between if/else branches

3. The mismatched type between arms of one match.

[burntsushi]

Is there a summary somewhere on what the state of try ... catch and Ok-wrapping is? I just read through some of @Nemo157 links (and then some), and I can’t make heads or tails of the situation. Is the RFC that introduced catch expressions still accurate?

I really do not want this thread to devolve into a debate about Ok-wrapping. I’m interested in understanding what the current state is and, if possible, where the most productive place to leave feedback would be.

[H2CO3]

Exactly, for this reason I was trying to search for the latest Ok-wrapping RFC to hopefully form a more informed opinion on it, but unfortunately the only one I was able to find was the one already mentioned here. Which by the way has been closed, so I’m not sure if it’s in sync with the currently implemented or expected behavior.

[Nemo157]

As far as I can tell #49371 is the last relevant PR and makes try-blocks work exactly how catch-expressions were specified to work in the RFC (modulo being extended to support the Try trait rather than being hard-coded to Result). The tracking issue would definitely be the place to discuss this further, but as @scottmcm “recently” said this would be re-re-raising an issue that has been debated many times before.

---

Which by the way has been closed

What do you mean by that? The RFC was accepted years ago and the tracking issue is still open waiting on stabilisation.

[burntsushi]

What do you mean by that? The RFC was accepted years ago and the tracking issue is still open waiting on stabilisation.

That RFC explicitly did not stabilize catch expressions. I remember that very clearly because it was a compromise made in order to stabilize ?, which had much more consensus. I also remember this because I had concerns about catch at the time but decided not to voice them because they weren’t on the table for stabilization. I don’t have time right now to go back through the hundreds of comments and tell Github 10 times to really show me every hidden comment to find where this was said, but it should be there.

[withoutboats]

RFCs are not usually how we stabilize things, and I think you’re conflating two different events:

• We merged an RFC which contained both ? and catch expressions.
• We stabilized the ? expression on Result, but nothing else from the RFC through an issue FCP.

Further changes have been made since then, but we accepted an RFC to have catch expressions on nightly under a feature flag way back in 2015.

The original RFC specified that the final expression of a catch block is expected to unify with the “ok” type of the result (i.e. it is “ok wrapped”).

(We’ve since also stabilized ? on Option, but I believe still nothing else from that RFC.)

[burntsushi]

Thanks for the clarification, although I think I’m just more confused than I was before. What was the concrete distinction being made by having that RFC be accepted for ? without stabilizing catch expressions? My understanding, I think, was that there would be an opportunity to further discuss whether catch should be stabilized. Did I just miss that discussion? If so, it happens. It’s hard to keep up! Or is the discussion still going on? And what exactly is it that is going to be stabilized?

[withoutboats]

Thanks for the clarification, although I think I’m just more confused than I was before. What was the concrete distinction being made by having that RFC be accepted for ? without stabilizing catch expressions? My understanding, I think, was that there would be an opportunity to further discuss whether catch should be stabilized. Did I just miss that discussion? If so, it happens. It’s hard to keep up! Or is the discussion still going on? And what exactly is it that is going to be stabilized?

There are two major “consensus seeking” milestones in the lifetime of a feature: when the RFC is accepted (allowing it to be implemented on nightly), and when the stabilization FCP is completed (allowing it to be stabilized). Catch expressions passed the first milestone in 2015 (as part of an RFC that also includes the ? expression and other things), but have still not passed the second milestone.

Your posts are conflating “RFC merged” with “feature stabilized.” No one has ever even proposed to stabilize catch expressions, AFAIK.

[burntsushi]

OK, I went back to the thread and now see why I was confused. Everyone on that thread is using “stabilized” like how I’m using it here. e.g., https://github.com/rust-lang/rust/issues/31436#issuecomment-251681299 — I think probably our conception of the RFC/stabilization process has crystallized a bit more since then, but my head was still stuck in 2016.

[H2CO3]

Sorry, I meant that the PR was closed – and I confused it with the RFC being closed. (I though the PR was supposed to be merged – it doesn’t matter much, though.)