Skip to content

Regression in integer fallback #21595

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SiegeLord opened this issue Jan 24, 2015 · 6 comments · Fixed by #21806
Closed

Regression in integer fallback #21595

SiegeLord opened this issue Jan 24, 2015 · 6 comments · Fixed by #21806
Labels
A-type-system Area: Type system

Comments

@SiegeLord
Copy link
Contributor

This code compiled fine before 1.0.0-nightly (4be79d6 2015-01-23 16:08:14 +0000):

fn main()
{
    for i in 0..100
    {
        i as f32;
    }
}

But with that version, it now gives this error:

<anon>:5:3: 5:11 error: the type of this value must be known in this context
<anon>:5        i as f32;
                ^~~~~~~~
@ghost
Copy link

ghost commented Jan 24, 2015

changing 0 to 0u32 should work, I stumbled upon the same thing and the doc seems to be updated: http://doc.rust-lang.org/book/looping.html (see at the very bottom)

EDIT: Maybe worth noting that these work:

    for x in 0..10 {
        println!("{}", x);                                                       
    }

    for x in range(0, 10) {
        println!("{}", x);
    }

    for i in range(0,100)
    {
      i as f32;
    }

@SiegeLord
Copy link
Contributor Author

That's just a workaround to a bug (not sure if that was implied). i should fall back to being i32 as per the existence of the integer fallback.

@nikomatsakis
Copy link
Contributor

I don't necessarily expect this to work. Fallback comes late in the process, once all constraints are known, but as (like method dispatch) requires the type being cast to be known immediately.

@nikomatsakis
Copy link
Contributor

It's plausible we could make it work since we know that the type is integral (I imagine that's how it ever worked, not sure what would have changed that, though it might have been something I did). It occurs to me though that this is somewhat forward-hostile to the idea of integer literals ever being used for anything other than plain ints (but enabling such a feature may well wind up requiring opt-in anyway).

@nikomatsakis
Copy link
Contributor

(Though really it's sort of silly that as requires the type to be known immediately, so I guess fixing that would be another way to ease the forward compat fears.)

@kmcallister kmcallister added the A-type-system Area: Type system label Jan 24, 2015
@ghost
Copy link

ghost commented Jan 24, 2015

I thought this was a feature because it's saying that it doesn't know if it's u32 or i32 for example. Would it assume it's unsigned only if it contains negative numbers in the range?
EDIT3: what @SiegeLord said makes sense: https://github.com/rust-lang/rfcs/blob/master/text/0212-restore-int-fallback.md


EDIT2: ignore the following, my bad
But I might be missing something because this doesn't output anything from for:
EDIT: just realized -1u32 is too big 4294967295 so the following makes sense:

fn main() {
  for i in -1u32..3 {
    if i % 2 == 0 {
      print!("*");
    }
    print!("{}",i);
  }
  println!("");
}
$ rustc main.rs && ./main 
main.rs:2:12: 2:17 warning: negation of unsigned int literal may be unintentional, #[warn(unsigned_negation)] on by default
main.rs:2   for i in -1u32..3 {
                     ^~~~~

There's no output from for, unless using -1i32

edwardw added a commit to edwardw/rust that referenced this issue Feb 1, 2015
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.

This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.

Closes rust-lang#21595
Closes rust-lang#21649
Closes rust-lang#21672
bors added a commit that referenced this issue Feb 1, 2015
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.

This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.

Closes #21595
Closes #21649
Closes #21672
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants