Tracking issue for `literal` fragment specifier (RFC 1576)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1576.

[durka]

Is anyone working on implementation already? If not I can take a crack at it.

[LeoTestard]

I'll probably do it.

[LeoTestard]

Huh oh, we have an issue already: do we mean to include potentially minus-prefixed literals? If yes, we have a problem because 1. it means we have to return an Expr instead of a Lit, which means I'm not sure one will be able to use the bound fragment in a non-expr context (for example in a static array type?) and 2. it's no longer always a single-TT, so the benefits in terms of future-proofing are a bit less good. If we don't... well, we loose expressivity. I have no idea what is more intuitive though... Would you, as a Rust user, expect $l:lit to parse -5? I certainly can think of use cases for this...

[nikomatsakis]

@LeoTestard good point. I think I would have expected it, yeah...but I also agree with the complications.

[durka]

Can't we upgrade Lit to support negative literals?

[joshtriplett]

@LeoTestard I'd expect "literal" (or a future integer-literal specifier) to include -5 (negative 5), but not - 5 (the negation of positive 5).

Perhaps that expectation doesn't match reality, though. For instance, based on parsing rules for non-literals, I'd expect -5.function() to act like -(5.function()).

So, if handling both -5 and - 5 as literals makes this easier, that works. But "literal" definitely needs to include negative numbers, or we'd have a weird user trap to explain.

[petrochenkov]

@joshtriplett

I'd expect "literal" (or a future integer-literal specifier) to include -5 (negative 5), but not - 5 (the negation of positive 5).

Unary operators, including minus, are processed purely by the parser at the moment, no lexer involved. So their treatment is whitespace agnostic.
(I personally think this is a good thing.)

[LeoTestard]

I agree with @petrochenkov. -5 is not syntactically different from - 5 and has no reason to be.
But I also agree with the fact that the user will probably expect negative numbers to work as literals (even it – syntactically – they're not).

[petrochenkov]

- literal is also supported in literal patterns while arbitrary expressions are not.

fn main() {
    match 10 {
        -1 => {}
        -3 ... -2 => {}
        _ => {}
    }
}

It'd be reasonable to support it in fragments as well.

[jorendorff]

Another thing that won't match is a macro call, like concat!("hello", "world"), or any of the other macros that I think of as expanding to a literal (include_str!, env!...).

I dunno, maybe this is not such a good idea after all. Re-reading the RFC in a more skeptical light, I felt like the "Motivation" section could use some more concrete use cases. Maybe this is just failure of imagination on my part, though!

I think the likelihood of this feature attracting people who really want constant expressions should be acknowledged as a drawback, too.