Some API design criticisms

[rodrimati1992]

Here I'll give some criticisms (and alternate designs) of the API, repeating some I've just given in the community server macros channel.

I've found TyExpr's name confusing, because I expected it to be an expression, but it's actually just a type. It's conflating two syntactically distinct things in its name.

In Attributes, tk_braces is not a pair of { and }, which is what proc_macro and syn call Brace. To be consistent with both it'd have to be tk_bracket.

In Attributes, tk_equals, tk_group, tk_value would be better modeled as an Argument, where Argument is these variants:

• Path: for #[foo]
• Group{span: Span, value: Vec<TokenTree>}: for #[foo(bar baz qux)]
• EqualsValue{equals: Punct, value: Vec<TokenTree>}: for #[foo = bar]

Argument would also have methods for getting the tk_* fields that were rewritten into it.

This design for Attributes removes mismatched Option fields (ie: tk_equals is Some, but tk_value is None), so users don't have to return errors (or panic) when they're mismatched anymore.

[PoignardAzur]

Type expressions are a valid Rust construct. But maybe I'll change the name.

Otherwise, your criticisms make sense.