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
