RE: Pre-RFC: Break with value in for/while loops

[RustyYato]

Pre-RFC: Break with value in for/while loops

Any other uninhabited enum can also be easily converted to any type, it's just a match x {}. There is vacuously only one way to perform such a conversion, so the question of whether to make it implicit is purely a matter of convienience, not correctness; it's just that Rust mostly avoids implicit conversions. The one from ! was added mostly for backwards-compatibility reasons, so that code continues to compile after the type of return changes from () to !. So ! is a bit special, but not enough …

@felix.s

• It does generalise well, though. Read especially the last bit. What a shame that issue got derailed by people who don't understand type theory.

This is uncalled for. I do understand type theory, and uninhabited types would work seemlessly with the generator solution.

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

@felix.s

Have you thought about how this is going to interact with generics and non-exhaustive empty enums? The whole question of whether a type is inhabited or not is going to significantly compilcate reasoning about types wherever a for loop appears.

This should just fall out of the generator desugaring I showed above.

@felix.s

What I meant by conceptual purity is making features orthogonal: useful independently of each other and interacting in simple, predictable ways.

Yes, this is what I mean as well

@felix.s

A well-designed for loop would be usable on its own, even if the language did not have any combinators at all. (Combinators aren't going anywhere, of course. But the for loop should still be usable as it stands.)

I don't know about this. Iterator is pretty useless without combinators. (You can't easily iterate over two things in lock step). Also chaining iterators is now impossible, and oh look, fairly useless iterators. At this point iterators are only useful as a minor performance improvement. (While this may be enough, it isn't what makes Iterator the perfectly designed trait that it is)

@felix.s

The generator proposal hopelessly tangles together for loops and combinators even in its motivating use case (I cannot stress this enough), and you're suggesting to add reasoning about inhabitedness to the mix? No, just no.

The compiler can reason about inhabitedness so you don't need to.