Skip to content
This repository has been archived by the owner on Jul 19, 2020. It is now read-only.

Bring back {}, {*}, and {3} capture syntax for tuple structs/enums. #116

Closed
hgzimmerman opened this issue Oct 19, 2019 · 1 comment · Fixed by #155
Closed

Bring back {}, {*}, and {3} capture syntax for tuple structs/enums. #116

hgzimmerman opened this issue Oct 19, 2019 · 1 comment · Fixed by #155
Labels
enhancement New feature or request high priority Issues with this tag will be worked on before others

Comments

@hgzimmerman
Copy link
Member

Description

Currently, the same syntax is used for both tuple-structs and normal structs,and unit structs.
The current implementation requires a name for each capture group, even though they aren't used for tuple-structs. A superset of the syntax could be introduced to support tuples, allowing both unnamed and named variations on the {} syntax.

To keep the implementations similar, a parameter or or type parameter could be provided to the frontend parser function.
The MatcherToken could get a superset copy of itself, or could be expanded to hold both. The advantage of keeping them separate, is that one could only produce Captures and the other one Vec<String> when matching, but would likely require a duplication of a lot of otherwise sharable logic as a downside.

@hgzimmerman hgzimmerman added enhancement New feature or request low priority Other work will take precedence over this. Speed of work may be dependent on external interest. labels Oct 19, 2019
@hgzimmerman
Copy link
Member Author

Instead of creating a whole new parser system, just pass in an enum representing either Named / Unnamed&Unit, and special case the captures.

@hgzimmerman hgzimmerman changed the title Create separate frontend for matching unnamed fields Bring back {}, {*}, and {3} syntax for tuple structs/enums. Oct 24, 2019
@hgzimmerman hgzimmerman changed the title Bring back {}, {*}, and {3} syntax for tuple structs/enums. Bring back {}, {*}, and {3} capture syntax for tuple structs/enums. Oct 25, 2019
@hgzimmerman hgzimmerman added high priority Issues with this tag will be worked on before others and removed low priority Other work will take precedence over this. Speed of work may be dependent on external interest. labels Oct 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request high priority Issues with this tag will be worked on before others
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant