Ok(()) looks so weird

community
1

...

		CountForKitties::<T>::set(new_count);
		Self::deposit_event(Event::<T>::Created { owner });
		Ok(())
	}
2

What, and ::<T>:: does not?

Funny what people get used to. Isn't it?

3

enjoy some weird-exprs.rs

fn semisemisemisemisemi() {
    ;;;;;;; ;;;;;;; ;;;    ;;; ;;
    ;;      ;;      ;;;;  ;;;; ;;
    ;;;;;;; ;;;;;   ;; ;;;; ;; ;;
         ;; ;;      ;;  ;;  ;; ;;
    ;;;;;;; ;;;;;;; ;;      ;; ;;
}

:smile:

4

Ridiculously, they call it fish syntax

5

You're not the only one that finds Ok(()) weird enough to think about how to get rid of it, in fact, probably over the years quite considerable amounts of thought must have gone into ways the common need for it could be eliminated. E. g. here was an IRLO discussion about it. It's just hard to do without any relevant downsides, be it too much complexity for too little benefit, or some loss of explicitness which when kept could help make code bases more robust.

6 
#[allow(non_snake_case)]
fn Ok() -> Result<()> {
    Ok(())
}
// or
const OK: Result<(), Box<dyn std::error::Error>> = Ok(());

:laughing:

7

I have an idea, using the async like grammar, with become keyword:

// if we decided to make the grammar like async fn foo() {}
Result<_, E> fn foo() {} // return Ok(())
// actually, the normal grammar should be enough
fn foo() -> Result <(), E> {} // return Ok(()), this might be valid in Rust 2027. Due to compatitable reasons, we cannot accept it now.
// if we want to both accept the old style and new style:
fn foo() -> try Result <(), E> {}

// Such grammar follows 2 rules:
// 1. all the return values are wrapped
fn foo() -> Option<i32> { 42 } // return Some(42)
fn bar() -> Option<Option<i32>> { foo() } // return Some(Some(42))
// 2. If we want to pass the value directly without wrapping, use `become`:
fn baz() -> Option<i32> { become foo() }

Maybe we need a new associate function in Try trait to tell compiler how to wrapping values

trait Try {
    fn warpping(Self::Resudial) -> Self;
    // ...
}
8

Please, no more obscure syntax or keywords.

9

Actually, become is a keyword.

#![feature(explicit_tail_calls)]
fn foo() -> i32 {
    become 42;
}
fn main() {
    println!("{}", foo()) // ICE now
}
10

Well I never.

It's so horrible.

Interestingly your example crashes my compiler!

11

That keyword is experimental, and both Rust said the feature is experimental, and I said that would yield an ICE.

warning: the feature `explicit_tail_calls` is incomplete and may not be safe to use and/or cause compiler crashes
 --> test.rs:1:12
  |
1 | #![feature(explicit_tail_calls)]
  |            ^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #112788 <https://github.com/rust-lang/rust/issues/112788> for more information
  = note: `#[warn(incomplete_features)]` on by default
12

Everyone has the "bright" idea to auto-Ok-wrap expressions in some horrible, exception-like mechanism every once in a while.

Just don't. Get used to it. It's uniform, it's trivial, and it doesn't have any real downsides.

13

So you did. I don't know what is "ICE".

14

Internal Compiler Error.

15

Thanks.

16

I see you never tried to break rust :wink:

17

Ha!

18

I wonder whether the compiler could be tweaked to allow returning Ok(_) in cases where there is just one possible instance of a type, such as unit.

20

i fixed the first one so it actually compiles:

#[allow(non_snake_case)]
fn Ok<E>() -> Result<(), E> {
    Result::Ok(())
}
21

The current accepted solution for Ok-wrapping is try blocks, and possibly (but not definitely) try-functions. Playground

#![feature(try_blocks)]
fn buritto(x: u32) -> Result<u32, ()> {
    try { x }
}