cross-posted from: https://diode.zone/videos/watch/9766d1f1-6018-48ec-ad67-e971758f8a3a
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/A1-intro-to-rust
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.
In the last exercise (
05
), I ran quickly tried to extend it into creating “unfloored halves” (you’ll know what I mean if you look at the exercise) … and ran into the process of initialising empty arrays.What I hit upon is:
let mut floating_data: [f32; 5] = [0.0; 5];
Where the
0.0
in[
is necessary it seems?? And you can’t simply have ]let floating_data = [f32; 5];
… ?From what I gathered, the general syntax is
[
, where ]EXPR
is actually evaluated, presumably to define the required memory/type, even though the type of the array (in the code above,f32
) also constrains the type of elements of the array.In the code above, as the default float type is
f64
, the typing of the array as[
actually constrained or affected the way that the expression of ]0.0
in the array literal was used to build the array.So why do I need to provide both so that they interact in this weird and implicit way?? Unless I’m missing something, surely something like
let floating_data = [f32; 5];
would be better? Putting that0.0
because it just needs to be there is tolerable but a bit off IMO.f32
is a type, you need to actually provide a value to the shorthand array initialization syntax, the array is filled with that value. There is no such thing as “uninitialized” or implicit zeroing here.let foo: [f32; 5] = [0.0; 5];
You seem to have indicated dismay over the default f64 type.
To type a integer or float literal, suffix it with its built-in type. For example:
0.0f32
1024usize
Does this look ugly? Yes. Good news! It’s hardly relevant in an actual project because Rust will easily default to whichever float type you are using throughout the project as your floating point numbers with resolved types will resolve the types of the implicitly typed floating point numbers.
You can also use the same syntax with the
vec![]
macro :)let bar = vec![0.0f32; 5];
Shouldn’t we be able to do something like
let bar : [f32; 5] = [Default::default(); 5];
?
I’m on mobile and too lazy to try whipping up a rust playground example to test this out myself.
I’ll do you one better!
let foo: [u8; 10] = Default::default();
(pretty sure the above only works reliably after they finally were able to derive traits on n-sized arrays but that’s been in for a while now)
And as you suggested:
let foo: [u8; 10] = [Default::default(); 10];
Thanks!
I recognise I was getting nitpicky there, just figured it might help someone else avoid confusion around it.
And yea, I figured I’d make sure I knew how to set the numeric type of my choice rather than just rely on inference.
Otherwise, I think I hate the postfix typing, I just can’t bring myself to use it lol.
But thanks for the help!!
So getting setup to actually attempt these exercises yourself before seeing the answers in the video takes a little bit of work.
Having just got set up, I’ll share the process here. What’s nice about it is that it seems to be kinda TDD exercises … ie you run
cargo run
, which runs some tests, which fail, and you have to fix things until tests pass or compilation can happen. Not a bad way to write exercises IMO.But it does require a few steps to set up the repo, which also seems to be somewhat over engineered for an introductory course (just some friendly feedback there Andy if you’re reading this).
You can see their “official” docs on this here: https://101-rs.tweede.golf/0-install/mod.html
- Have cargo installed (basically use rustup, see “The Book” or the docs linked above)
- Clone repo at: https://github.com/tweedegolf/101-rs
- Build the materials (this is basically compiling a rust program to then put the materials together from the raw content in the repo):
- Create a directory for where you want to dump the built materials. I created
intro_track/
alongside the repo’s directory - From inside the repo (named
101-rs
, navigate to./modmod/
- run
cargo run -- -o target/course -c ../content/rust-intro.track.toml
wheretarget/course
is the directory you created above for containing these materials.
- Create a directory for where you want to dump the built materials. I created
- Navigate to
course
(where materials were dumped). There’ll you find./exercises/2-foundations-of-rust/1-foundations-of-rust/
. In this directory will be numbered subdirectories including1-basic-syntax
and2-move-semantics
etc. Each one is a rust/cargo project and represents a module or something of the course. - The idea being, I think, that completing the exercise will be when
cargo run
works without errors.
I missed the last step really.
So you need to navigate into one of these subdirectories like
.../1-basic-syntax/
. Which, as I said above, is a rust/cargo project.From there, you run
cargo run
to see if it compiles (it likely won’t until you fix the code, which is the exercise).OR, you run
cargo test
to run the tests (which, again, will likely not pass).If the project has mulitple files, each being their own exercise, then you have to use
--bin
to specify which file/bin you want to run. EG:cargo run --bin 01
for a file named01.rs
. Or,cargo test --bin 01
for the tests in a file named01.rs
.Another interesting to note here is there’s a basic introduction to writing and running tests in rust!
As you’ll see in the video, Andy himself seems to be a TDD guy and starts writing a test before just completing the exercise.
Ok, so the first exercise here
1-basic-syntax/01.rs
throws me a little bit. With the compiler error it’s easy enough to fix, but conceptually I didn’t actually have this down.fn multiply(a: i32, b: i32) { a * b }
This function is invalid. The crucial error from the compiler is:
error[E0308]: mismatched types --> src/bin/01.rs:6:5 | 5 | fn multiply(a: i32, b: i32) { | - help: try adding a return type: `-> i32` 6 | a * b | ^^^^^ expected `()`, found `i32`
So the quick fix it needs is a return type. That’s fine.
The bits that throw me are:
- The default return type is an empty tuple? (whatever is meant by
()
). - There is no type inference on the return type? For
let v = a * b;
rust is happy to infer thatv: i32
, why not a function’s return? I’d guess some policy of ensuring function declarations are clean with respect to types and reaping the compiling and safety features that follow that.
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 theDisplay
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.Thanks!! Very helpful!
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.
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.
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”.
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.
- This function returns a unit type
- 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
- The default return type is an empty tuple? (whatever is meant by