Rust 101 - 4: Exercises for module A1

freamon@futurology.today · 10 months ago

Rust 101 - 4: Exercises for module A1

Jayjader · 9 months ago

I found a more precise answer re: type inference: https://stackoverflow.com/questions/24977365/differences-in-type-inference-for-closures-and-functions-in-rust

As I understand it, if a function is public you will need to explicit the return type. If it’s private/local/not visible from outside the module wherein it is defined, then inference can kick in.

But generally, you’ll want to specify the return type to make the compiler that much more aware of your intent.

maegul (he/they)@lemmy.ml · 9 months ago

That makes a lot of sense. Intuitively I figured it would be something like that.

Still, as a compilation error, it’s confusing to see an error on the unit type being inconsistent when the issue is really an untyped return. Though now I know what the unit type is it’s a bit clearer what such a compiler error is about.

deur@feddit.nl · edit-2 9 months ago

This behavior is simple, it just wasn’t explained to you at the correct level.

All blocks (code between { and }) evaluate to some value, they’re all treated as expressions. A function “without a return type” will always return () because that’s what a block that doesn’t have any “output” “returns”.

This understanding is fundamental to Rust and, for example, is involved in understanding when we have to and don’t have to use return in a function. Quite usefully, it also allows us to organize our code by creating a new scope, i.e.

let foo: u32 = {
    // Hate dropping mutex guards explicitly? This is one way you can avoid that (although it's arguably a code smell that I discourage and should not have even mentioned)

    // This block evaluates to 100
    100
};

let foo: () = {
    println!("this block evaluates to the unit type");
}

The way Rust interprets the issue with your function is:

This function returns a unit type () because it doesn’t have an explicit return value
The block that defines this function is evaluating to a value of type i32 which is not ()
errors

The reason the error is perhaps more unclear than it could be is because they assume you have read the Rust book or understand how blocks are expressions themselves.

It would be valuable to look at https://doc.rust-lang.org/book/ch03-03-how-functions-work.html for more details and to gain a more thorough understanding of the topic at hand. I left out the precise details on “which expression from the block is the one that it evaluates to” other than the obvious case of “the very last expression”.

maegul (he/they)@lemmy.ml · 9 months ago

The reason the error is perhaps more unclear than it could be is because they assume you have read the Rust book or understand how blocks are expressions themselves.

I’m not so sure that this is the issue. I understood that blocks are expressions. The issue was that I didn’t know that type inference doesn’t apply to function returns (generally). That such is not true is easy to guess, but I’d presumed as much because the task of inferring seemed no more difficult than local variable type inference.

And so given that it’s such a simple and essential requirement, I’m not sure it wouldn’t be simpler and better to have a compiler error that simply states that an explicit return type is required.

Seeing instead that the return type was understood to be the unit type is also confusing as the function block clearly had a return value (here, AFAIU, explicit/implicit return makes no difference). So instead of wondering about the need for an explicit return type I immediately wondered about what type the function was actually returning (ie, had I accidentally created ()).

Of course I didn’t know about the unit type etc. But even so, as a compiler error, it’s represented in pieces rather than cutting to the core requirement of an explicit return type. Perhaps a reminder better left to a linter. I’d guess clippy warns you about this, but I thought I’d just rely on the compiler for as long as I can.