Remove nesting from let else example

[randomPoison]

I think focusing on deeply nested control on this slide distracts from the main point of the slide. The slide frames let else as the solution to deep nesting, when it's really the early returns that allow for the simplification (at least in this example). This makes it harder to explain let else to students because we're simultaneously changing the control flow structure and introducing a new language construct. I think if we started with a match-based example that's already using early returns it'd be clearer to students how let else can be a more concise version of match in cases like this.

If this seems like a bad idea to others I can change this to move the match-based version into the speaker notes. That'd at least make it easier to first show the nested code, then an unnested version using match, and then finally an unnested version using let else.

[fw-immunant]

The RFC introducing let-else specifically motivates it with reference to rightward drift of nested if lets. In other more "functional" languages like Standard ML and OCaml, there's no cultural consensus to de-nest (nor great syntactic support for it), but in systems languages like C it's more encouraged, e.g. in the Linux kernel. I think this discussion is good to show where Rust sits in the space of these different languages and approaches, synthesizing functional and imperative approaches.

[randomPoison]

Talking about reducing rightward drift makes sense as a motivation for let else, but I think focusing on that here makes it harder for students to grok what let else is doing. We're effectively doing two things at the same time:

• De-nesting by making use of early returns.
• Using let else to concisely early return on failed pattern matches.

I get what you're saying about demonstrating the norms in rust around de-nesting and early returns, but I think that's less important than getting students to understand what let else is doing and how to use it. Would it make sense to add the fully-nested version to the speakers notes under "More to Explore"? Talking about nesting is a secondary goal here, but still potentially a good thing to cover if there's time.

[djmitche]

What if we strike a balance here:

Suggested change

	let s = match maybe_string {
	Some(s) => s,
	None => return Err(String::from("got None")),
	};
	let s = if let Some(s) = maybe_string {
	s
	} else {
	return Err(String::from("got None")),
	};

[randomPoison]

I'm not sure how this helps? Using if let spreads it across more lines vertically, but doesn't demonstrate any more nesting. I'd say using match here is clearer, but I guess I don't feel that strongly about it.

[djmitche]

Fundamentally, the thing that people get into here is "I need to pattern-match some enums, with an early exit if they don't match". I think the let .. = if .. else { return .. }; is a clearer representation of this desire than the match, since match doesn't represent the "else" as clearly.

[randomPoison]

since match doesn't represent the "else" as clearly.

... isn't the None case the same as the else case? Are you saying that the None case in a match might be less clear to students than else is, since they'd be more familiar with if else coming from other languages?

[randomPoison]

Oh, I guess the change from if else to let else might also be a more direct transformation than going from match to let else?

[djmitche]

Yes, I'm saying both of those things :)

[randomPoison]

Okay, I've changed it to use if let instead. @fw-immunant does this seem any better to you? The starting code still doesn't have any nesting, but we're now using if let instead of match, which maybe helps address your point about the motivation for let else?