Fragment Specifiers for Generic Arguments

[JarredAllen]

I wrote up my thoughts from this rust-internals thread into an RFC.

Rendered

[programmerjake]

don't word-wrap in the middle of a ` code span, it doesn't get rendered properly

[JarredAllen]

Oops, I guess I need a better editor config. Fixed in d77ac90

[oxalica]

This RFC does not include specifiers for where-clause, which is highly related to generics. Is this intentional? Maybe we should mention this in text.

[oxalica]

const N does not work for the macro example above, $param:generic_param $( : $bound:generic_bound )?. Const generics have the syntax const $param:ident : $ty:ty $(= $default:expr)?. Note that it is a type instead of generic bounds after the colon, so syntactically it should also accept non-trait-like types like const N: (i32, i32), though it's forbidden currently.

[JarredAllen]

This was a deliberate deviation from the default syntax to make it easier to parse an arbitrary set of generic parameters. If we use the fragment specifiers as I defined them in the example macro defined in the RFC (< $( $param:generic_param $( : $bound:generic_bound )? ),+ > , then this successfully matches <const N: usize> ($param being const N and $bound being usize.

If it matches as you're requesting that it match, then the same pattern will match this trait, but it will also allow in nonsense like <const N: usize: 'a + SomeTrait> which my approach avoids. I'm not sure how one could change the pattern to avoid allowing for nonsense like that.

Though also, my approach would match <const N>, which is also nonsense, so idk which one would be better to reject while matching the macro. I'm open to changing it if you have arguments for your way of splitting the definition between the two fragment specifiers being better.

To your last point, the definition that I give for :generic_bounds does explicitly allow for a type, so that syntax would be accepted.

[Aloso]

Your approach also matches const N: 'a and 'a: usize (see my comment below)

[oxalica]

Should it be named "generic_bound" or "generic_bounds"?
Also that TypeParamBounds does not allow empty, while the generic syntax do allow <T: /*nothing*/> (except for const generics). If we want it to match multiple bounds, it should also match no bounds.

[JarredAllen]

Neat, I never knew that Rust allowed <T:> as a generic parameter list. That doesn't seem very useful to me, but I'll change it to allow that since I agree that it should be matched if Rust allows it.

[clarfonthey]

This RFC does not include specifiers for where-clause, which is highly related to generics. Is this intentional? Maybe we should mention this in text.

I think this would be nice longer-term, but at least for now, the extremely simple case of being able to check for pieces like <T, const N> without resorting to using token-trees is pretty good on its own. That said, the inclusion of bounds in this RFC does beg the inclusion of where bounds too.

[Aloso]

I like the general idea of this RFC, but I don't like that a macro accepting $( $p:generic_param $( : $b:generic_bound )? ),* can accept illegal syntax (like a lifetime followed by a trait bound, or a const generic followed by a lifetime bound).

I also don't like that matching all generics syntax with the more granular fragments is pretty verbose:

< $(
    $( #[$m:meta] )*
    $p:generic_param
    $( : $( $b:generic_bound )? )?
    $( = $d:generic_default )?
),* $(,)? >

a where clause could be written like this, if we require trailing commas:

where $(
    $( $l:lifetime $( : $( $b1:generic_bound )? )? , )?
    $( $( for $f:generic )? $t:ty $( : $( $b2:generic_bound )? )? , )?
)*

But this isn't forward compatible with

• return type notation (where Self::method(): OtherTrait)
• equality constraints (where Self::ID = {N + 1})
• possibly more

[Aloso]

Maybe it would be best to remove :generic_param, :generic_bound and :generic_default from the RFC (unless you can give an example where they're useful), and instead add :where_clause.

[JarredAllen]

I added a :where_clause, as per multiple requests. They were excluded initially because I forgot that they existed, not for any real reason.

[JarredAllen]

I like the general idea of this RFC, but I don't like that a macro accepting $( $p:generic_param $( : $b:generic_bound )? ),* can accept illegal syntax (like a lifetime followed by a trait bound, or a const generic followed by a lifetime bound).

I also don't like that matching all generics syntax with the more granular fragments is pretty verbose:

Yeah, sadly the only way to prevent it from accepting illegal syntaxes like const N: 'a or 'a: usize would make it even more verbose and complicated to match the entire generics syntax, which makes your other point worse. Though, you don't need the $()? around :generic_bound anymore, I didn't know that nothing could be put there and have since updated it to allow that, so it's slightly less verbose.

I tried to strike a happy medium where relatively few illegal syntaxes are allowed (I think they've all been said on this page? Unless I'm missing some) but also it's reasonably non-verbose to parse the full generic parameter definition syntax and we're not adding too many new fragment specifiers into the language, and the split is done in such a way that it could be useful for implementing macros.

I'm open to any suggestions you have for making that trade-off better, but this was the best balance between the two goals I could think of.

[CohenArthur]

maybe a nit but generic being singular confuses me. I think it would make more sense for it to be named generics or generic_set, or anything to add plurality to the concept, especially since it would be responsible for parsing the opening and closing angle brackets