# Break with value alternatives

**URL:** https://internals.rust-lang.org/t/break-with-value-alternatives/11240
**Category:** language design
**Created:** [November 5, 2019, 2:18pm UTC](https://internals.rust-lang.org/t/break-with-value-alternatives/11240 "2019-11-05T14:18:56Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![felix.s](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/felix.s/32/8073_2.png) [@felix.s](https://internals.rust-lang.org/u/felix.s)
#### Post date: [November 5, 2019, 3:11pm UTC](https://internals.rust-lang.org/t/break-with-value-alternatives/11240/11 "2019-11-05T15:11:44Z")

</div>

Regarding empty `match`es evaluating to `!`, which you mentioned in your last post, I think before `!` was introduced as a first-class type, `match x {}` evaluated to whatever type inference told it to. Though I don't really have a way to check if that's still true now (or was back then). And yes, `return`'s type was `()` before first-class `!` was introduced. I recall compiler people sighing with relief when they could finally remove special handling of unreachable code that was necessary because of that.

> [@RE: Pre-RFC: Break with value in for/while loops](https://internals.rust-lang.org/t/re-pre-rfc-break-with-value-in-for-while-loops/11238/1):
>
> I do understand type theory, and uninhabited types would work seemlessly with the generator solution.

I was referring to people being confused over whether `()` is a top type (which it obviously isn't). I don't even remember if you participated in that issue's thread, to be honest.

> [@RE: Pre-RFC: Break with value in for/while loops](https://internals.rust-lang.org/t/re-pre-rfc-break-with-value-in-for-while-loops/11238/1):
>
> After think about it a bit more, we don't actually need to special case based on inhabitedness. It would just fall out of the generator desugaring.
> 
> [Rust Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=fd5320f4b2b7f258ff8bfa45aa06aadf)

Ouch. I mean, yes, it compiles… but you're relying on `for` being a sugar for `loop`-`match` and on the `break` from the generator implicitly converting the `!` return value to the other `break`'s type. If `for` were a primitive construct which actually enforces that `break` agree with the return type of the generator (as a good abstraction should behave), it would not work. I think it's a deficiency of this desugaring that it does.

> [@RE: Pre-RFC: Break with value in for/while loops](https://internals.rust-lang.org/t/re-pre-rfc-break-with-value-in-for-while-loops/11238/1):
>
> I don't know about this. `Iterator` is pretty useless without combinators.

Sure you can chain `Iterator`s with just `for`, you just write two loops. Of course combinators make it more convenient, but they don't interfere with the usefulness of `for` for iteration on its own; `for` still does its job even if you don't have combinators. To contrast, the `break` semantics from the generator proposal diminish its usefulness for returning values from the loop quite significantly.

> [@RE: Pre-RFC: Break with value in for/while loops](https://internals.rust-lang.org/t/re-pre-rfc-break-with-value-in-for-while-loops/11238/1):
>
> The compiler can reason about inhabitedness so you don't need to.

As the cliché goes, code is written for humans to understand and only occasionally for machines to execute. When reading code, I want to think about `for` as a black box most of the time, without adding its desugaring to the cognitive burden of understanding it.

---

_[View the full topic](https://internals.rust-lang.org/t/break-with-value-alternatives/11240)._