What about
match bar {
0 .. (end - 1) = > ...
}
Shouldn't it include an expression?
On 25 April 2013 16:30, John Clements <[email protected]> wrote:
>
> 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
>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
