On Apr 25, 2013, at 8:34 AM, Lucian Branescu wrote:
> What about
>
> match bar {
> 0 .. (end - 1) = > ...
> }
>
> Shouldn't it include an expression?
Well, that's the question. Currently the grammar (and compiler) allow this. I'd
like to define a grammar here that nails down what's allowed a little more
tightly, rather than deferring entirely to (currently broken) constant
evaluation.
John
>
>
> 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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
