Going through some exercises on basic Rust syntax and ownership. Links: Exercises: https://101-rs.tweede.golf/A1-language-basics/mod.html, Slides: http://artificialworlds.net/presentations/rust-101...

cross-posted from: https://diode.zone/videos/watch/9766d1f1-6018-48ec-ad67-e971758f8a3a

Going through some exercises on basic Rust syntax and ownership.

Links:

Rust 101 is a series of videos explaining how to write programs in Rust. The course materials for this series are developed by tweede golf. You can find more information at https://github.com/tweedegolf/101-rs and you can sponsor the work at https://github.com/sponsors/tweedegolf . They are released under the Creative Commons Attribution Share Alike 4.0 International license.

This series of videos is copyright 2023 Andy Balaam and the tweede golf contributors and is released under the Creative Commons Attribution Share Alike 4.0 International license.

These videos are roughly on track with the Reading Club apparently, so this video belongs here this week, I think.

  • JayjaderMEnglish
    2·
    3 years ago

    I think I have some answers for you if you haven’t resolved them yet:

    • the default return type is not an empty tuple, but the unit type which basically represents a unit of computation being performed, without any data as output (i.e. purely side-effects are allowed). It is kinda the equivalent of void from java- and c-style languages. Here is a decent explanation on StackOverflow if you prefer that sort of thing.
    • there absolutely is inference on the return type (I’ve used it in other rust projects before), but I can’t remember if it only, or also takes into account how the function is externally called. In any case, this function’s sole use is on the line
        println!("{}", multiply(10, 20));

    And “sadly” (for us here), this doesn’t explicitly say “I am expecting an int/i32 as output of multiply”, it only says “I am expecting something that implements the Display trait”. I think that in such cases it defaults to assuming the unit type () because it is the “simplest”/“most conservative” guess the compiler can make in such cases.

      • JayjaderMEnglish
        2·
        3 years 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.mlMEnglish
          1·
          3 years 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.

            • maegul (he/they)@lemmy.mlMEnglish
              11·
              3 years 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.