Skip to content
This repository

typestate sees `break` as applying to the outermost loop #2642

Closed
paulstansifer opened this Issue June 18, 2012 · 14 comments

4 participants

Paul Stansifer Tim Chevalier Niko Matsakis Eric Holk
Paul Stansifer
Collaborator

The following code compiles (as expected):

fn main() {
    let _x: uint = loop { };
}

However, this code does not, as if the break were breaking out of the outer loop:

fn main() {
    let _x: uint = loop { loop { break; } };
}
Niko Matsakis
Collaborator

this may be a liveness bug?

Tim Chevalier
Collaborator

Maybe, but I'm pretty sure I know what the bug is if it's in typestate. @paulstansifer , can you post the error message?

Niko Matsakis
Collaborator

actually I think this is neither liveness nor typestate but rather typeck and something off in the (rather hokey) way that it tracks the notion of "bottom".

Niko Matsakis
Collaborator

this is the error that I see:

/Users/nmatsakis/tmp/issue-2642.rs:2:19: 2:43 error: mismatched types: expected `uint` but found `()` (uint vs ())
/Users/nmatsakis/tmp/issue-2642.rs:2     let _x: uint = loop { loop { break; } };
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~

Tim Chevalier
Collaborator

Yeah, not a typestate error. I can still take a look, though.

Niko Matsakis
Collaborator

To be honest, I am not sure that the type system ought to be in the business of tracking bottom.

Paul Stansifer
Collaborator

Oops, sorry folks. That's the same as the error I get.

Paul Stansifer
Collaborator

It's really useful if you want to return from inside an otherwise infinite loop, which is what led me to this bug.

Niko Matsakis
Collaborator

but why are you "assigning" the loop to a local variable in the first place?

Niko Matsakis
Collaborator

it seems to me that loops and complex constructs that may or may not be bottom should just have unit type. Something like ret or what have you can still have bottom type.

Paul Stansifer
Collaborator

I probably should've reduced it to an example that looks more like the code I'm interested in:

fn f() -> uint {
  loop {
    if some_cond { ret 8u; }
    loop { break; }
  }
}

In this case, we need bottom to acknowledge that nothing will ever fall off the end of the outer loop, preventing the need for a dummy, dead code ret statement.

Eric Holk
Collaborator
eholk commented June 18, 2012

I think I usually just use fail if I need to convince the compiler that some code will never run.

Tim Chevalier
Collaborator

Yes, but the point of introducing loop was to make it possible to omit fails in some common cases... so I'm with Paul at least until I look at the typeck code and decide it's too hard to fix ;-)

Niko Matsakis
Collaborator

Paul's example is more convincing. I guess we have to make it work due to the fact that loops are expressions and can appear in tail position in a block. sigh

Tim Chevalier catamorphism closed this in f331cd9 June 20, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.