On Apr 24, 2013, at 8:59 PM, Benjamin Striegel wrote:
> > would it be reasonable to restrict the left- and right-hand-sides to simply
> > be literals?
>
> Literals only? So then would the following be illegal?
>
> static END = 2;
> ...
> match bar {
> 0 .. END => ...
> }
Good! I knew there were forms I was missing.
so, from the grammar standpoint, we now have
RANGE_LIT = LIT_INT | LIT_FLOAT | ident
Other important ones that I'm missing?
John
>
>
> On Wed, Apr 24, 2013 at 6:36 PM, John Clements <[email protected]>
> wrote:
> Right now, the Rust parser accepts arbitrary expressions in certain pattern
> locations, most notably on the right-hand-side of a ".." range pattern. In
> talking to Patrick about this, though, he conjectured that it might be pretty
> easy to explicitly define the grammar of constants. In fact… for range
> patterns, would it be reasonable to restrict the left- and right-hand-sides
> to simply be literals?
>
> I was poking through the source code, and I found some reference to the
> possibility of these patterns being strings, which I found intriguing, but I
> couldn't make it work:
>
> fn f() -> int { 14 }
>
> fn main() {
> match ~"abc" {
> "abb" .. "zzz" => io::println(~"success"),
> _ => fail!()
> }
> }
>
> … yields this error:
>
> jclements-09740:~/tryrust clements> rustc /tmp/foo.rs
> Running /usr/local/bin/rustc:
> /tmp/foo.rs:5:8: 5:13 error: mismatched types: expected `~str` but found
> `&'static str` (str storage differs: expected ~ but found &'static )
> /tmp/foo.rs:5 "abb" .. "zzz" => io::println(~"success"),
> ^~~~~
> /tmp/foo.rs:5:17: 5:22 error: mismatched types: expected `~str` but found
> `&'static str` (str storage differs: expected ~ but found &'static )
> /tmp/foo.rs:5 "abb" .. "zzz" => io::println(~"success"),
> ^~~~~
> /tmp/foo.rs:5:8: 5:25 error: non-numeric type used in range
> /tmp/foo.rs:5 "abb" .. "zzz" => io::println(~"success"),
> ^~~~~~~~~~~~~~~~~
> error: aborting due to 3 previous errors
>
>
> … which seems to be suggesting that I use patterns like ~"abc", but those
> don't work either…. they signal a type error using "uniq", which I think… is
> a compiler bug. Erm. NOT IMPORTANT NOW.
>
> The real question is this: can we define a simple grammar for what's legal on
> the lhs and rhs of a "range" pattern? perhaps simply
>
> pat = …
> | range_lit DOTDOT range_lit
> ...
>
> range_lit = LIT_INT | LIT_FLOAT
>
> ?
>
> Note that LIT_INT includes LIT_CHAR in this grammar.
>
> I haven't been able to find any legal Rust programs that would be made
> illegal by this restriction, but perhaps there are funny corner cases: once
> things get beyond the parser, I have no idea what kind of crazy stuff goes
> on. :)
>
> As an additional benefit, it would eliminate bug/partial features such as the
> one above and the ICE I reported earlier today.
>
> John
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev