this post was submitted on 14 Feb 2024
17 points (100.0% liked)

Learning Rust and Lemmy

392 readers
1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.

Running Projects

Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities

Thumbnail and banner generated by ChatGPT.

founded 9 months ago
MODERATORS
[email protected]
[email protected]
[email protected]
17
Rust 101 - 4: Exercises for module A1 (diode.zone)
submitted 9 months ago by [email protected] to c/[email protected]
15 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 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.