-
Notifications
You must be signed in to change notification settings - Fork 61
Open
Labels
enhancementNew feature or requestNew feature or request
Description
From a discussion during #1 :
Now that I'm seeing how much structure there is to type parameters, I think we should tweak their
structure so that there is always a visible syntax node corresponding to each parameter (as opposed to the identifier and upper_bound node appearing as siblings within the type_parameters node).
==================
Type parameters
==================
class A[B, +C <: D, -E : F : G]
---
(compilation_unit
(class_definition
(identifier)
(type_parameters
(invariant_type_parameter (type_identifier))
(covariant_type_parameter
(type_identifier)
(upper_bound (type_identifier)))
(contravariant_type_parameter
(type_identifier)
(context_bound (type_identifier))
(context_bound (type_identifier))))))
Does that make sense? We could have a hidden helper rule called _type_parameter that is shared between the three. In addition, we should add the _type_parameter to the inline section of the
grammar. That will avoid actually creating that node at runtime for performance reasons.
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request