Killing `Ok(())` with `ok!()`

libs
1

There have been many discussions about how to avoid writing Ok(()) at the end of function:

Here I want to propose my solution, which only need std to expose one macro: std::ok!(), which will expand to Ok(()).

Then we can write functions like this:

fn try_foo() -> Result<(), CustomError> {
    // Do some hard stuff
    ok!()
}

The great point is that, as ! is used as the macro marker for Rust, it is also used to express a strong feeling in English, and "ok!" sounds like finally, after all hard work, we succeeded with much joy!

2 Likes
2

If ok() as a function wasn't accepted, I'm pretty sure there's no way ok!() as a macro would be accepted -- generally one should never use a macro when a function would work fine.

37 Likes
3

btw is it possible to extend the macro rules so that we could write something like:

fn try_foo() -> Result<(), Error> {
    ok!
}

directly?

I means, a bare macro invoke with no extra brackets.

4

Yes you are right. I forgot the possibility to infer generic return type :smile:

Is there any discussion against ok() as a function? Could you post some links?

5

Some prior discussion on the general topic:

I can't remember if we (libs-api) ever considered an ok() function. Some quick skimming of the above links did turn up this, but I'm not sure if it was ever seriously entertained.

At least speaking personally, I don't really think Ok(()) is a problem that ought to be solved. But opinions I think differ wildly about this.

29 Likes
6

Personally, i do think simply adding the ok() or ok!() for std prelude can just solve the problem. At least for me, the motivation to get rid of Ok(()) is just the weird double parentheses.

7

I don't see it as a major improvement – it's just superficial syntax. It doesn't even improve type inference or remove need for Ok in methods returning other values.

Having both syntaxes will only cause churn and bikeshedding about which form should be used in codebases.

It being "weird" is just a matter of getting used to it. It's consistent with what () is, and maybe the unit/void should have been a different symbol, but it's too late to change it.

35 Likes
8

Why does this, among all discussion this forum has, keep coming up?

Typing Ok(()) is 1 character more than the proposed solution. RA autocompletes it. It looks less weird if you've been using Rust for <1 year, and looks the same after that. And even if this was accepted, it would not "kill" Ok(()), there would still be code using the "old" syntax. I for example find Ok(()) to be more expressive of what's happening. And in your own code, you're free to do

fn ok<E>() -> Result<(), E> { Ok(()) }

It's literally one line of code.

Come on people, just get on with it! It's Ok(()).

25 Likes
9

Calm down bro, all we want is to make Rust better :slight_smile:

I have written Rust for over 5 years, and just as you said, it does look less weird as time goes on. And I do believe that some little change could improve the coding experience a lot, like the newly-added matches! and let-else sentence.

And yes, maybe I should just define and use that simple ok function by myself.

1 Like
10

It's fine, don't worry. And don't take it on yourself... I didn't mean to be rude, I just feel like this is such a small change that it isn't worth wasting effort on it. But tastes in syntax differ, I guess.

The more I think about it, the more I feel like my whole generic mutability thing is also just a syntax preference that many don't care about... with possibly little gain. Although a definitely more complex one.

2 Likes
11

I am a strong proponent of a proper Ok-wrapping in try blocks and try fns. But in my opinion ok!(), ok(), etc. are ad-hoc solutions which only reduce consistency of the language, so I prefer the current status quo over them.

8 Likes
12

try blocks fully solve the problem of trailing Ok(()), you just don't write anything. They are also strongly desirable for other reasons. Given that, it makes no sense to introduce any kind of ad hoc syntax, regardless whether it's good, bad, long, short. Whatever you propose would be instantly obsolete and deprecated the moment try blocks arrive.

Also note that in your own code it's trivial to define both an ok! macro and an error-polymorphic ok() function. Publish it as a crate if you think it's an issue worth bothering with.

9 Likes
13

The good news is that that part has been accepted: https://github.com/rust-lang/rust/issues/41414

My RFC to try to get try blocks ready to stabilize: Add `homogeneous_try_blocks` RFC by scottmcm · Pull Request #3721 · rust-lang/rfcs · GitHub

13 Likes
14

Good to know! Hopefully, as the next logical step try fns will be introduced as well. Personally, I don't care much whether they will look as try fn foo() -> Result<T, E> { ... } or as fn foo() -> Result<T, E> try { ... }. And there is still a name to decide for yeet. :slight_smile:

15

There's a standard problem in language design, where two different desires pull in different directions:

  • Minimizing the total surface area of the language that people have to know in order to read it. This pulls in the direction of orthogonality: using features X and Y together should work, and work in the obvious way, and you shouldn't need lots of special cases.
  • Optimizing the language for writing by expert developers. This pulls in the direction of more special cases, more helpers, more specialized language constructs, and so on.

On balance, Rust tends to aim for more orthogonality, ease of reading other people's code, and ease of learning. Ok(()) is easy to understand: it's () wrapped in Ok. It doesn't need "solving".

I think the most likely solution for writing it less will be Ok-wrapped try blocks.

12 Likes
16

After all, then we can write try {} instead of Ok(()) :upside_down_face:

(Yes, I'm joking. Though try { x } is actually useful sometimes)

5 Likes
17

I love Ok(()).

It perfectly expresses what it is meant to be. It could not be any better. Nothing weird about it.

I'd rather have try blocks with Ok(()) at the end than having Ok(()) magically inferred.

I don't want to replace Ok(()) with anything else - not a constant, not a function call, and certainly not a macro.

14 Likes
18

Mildly surprised nobody mentioned the possibiltiy of

pub const OK<E>: Result<(), E> = Ok(());

which would be used like this:

fn returns_result() -> Result<(), CustomError> {
     ...
     OK
}

(this isn't a serious proposal, I'm not bothered by the verbosity of Ok(()), just thought it warranted being mentioned)

2 Likes
19

I'd be slightly interested in something more like:

fn whatever<T, E>() -> Result<T, E>
where T: Default
{
  Ok(T::default())
}

And the name even works too!

1 Like
20

This can only be used in nightly due to generic const items are not stabilized yet. But this code looks cool for me.