Idea: explicit type parameters for derivation

language design
21

It kinda looks like type Foo<T> = Bar, so there is some precedent in the language for this syntactic form, but I agree that path < args > = value looks weird (esp. without type in front).

22

If you allow #[foo<T>(...)] I don't think e.g. #[foo<T> = Option<T>] is weird. It does seem natural given that we allow fn foo<T>(...) and as @RustyYato pointed out type Foo<T> = Bar;.

However, I also did not set out to explicitly support #[foo<T> = ...] and that it happens to be supported is more an incidental fact that I don't see as a negative.

To actually avoid it you would need:

Attr = "[" path:Path input:AttrInput? "]" ;

AttrInput =
  | "=" LITERAL
  | generics:AttrGenerics? input:DelimAttrInput
  ;

DelimAttrInput =
  | "(" TOKEN_STREAM ")"
  | "[" TOKEN_STREAM "]"
  | "{" TOKEN_STREAM "}"
  ;

AttrGenerics = "<" TOKEN_STREAM  ">" ;

which seems somewhat more complicated.

Is there a lot of benefit to that complication?

23

None of the alternatives to the derive_no_bound RFC here allows for trait bounds on field types without repeating said types, making this proposal strictly less powerful than what I would want from such feature.

24

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.