Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a Arg::custom_parse style function #1185

Closed
kbknapp opened this issue Feb 16, 2018 · 3 comments
Closed

Provide a Arg::custom_parse style function #1185

kbknapp opened this issue Feb 16, 2018 · 3 comments
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this

Comments

@kbknapp
Copy link
Member

kbknapp commented Feb 16, 2018

Something I've been thinking about for a while and mentioned in BurntSushi/ripgrep#809 is to add some additional functions which allow users to do something mid parse. From the linked issue:

The other way would involve something I've been thinking about, which is to provide companions to the validators, namely the ability to provide functions to Filter/Skip, Map, and Action arguments mid parse. These would do things such as do something potentially impure (Action), allow one to filter/skip values (Filter/Skip haven't decide on naming yet), or transform actual values themselves (Map) to be saved in the matches struct. These would all have access to the matches struct as it exists at that time, in order to perform decisions or possibly even mutate. I should say though that this method is further off and would not be available until v3 at the earliest (if ever, pending design and implementation, etc.).

However, now that I'm thinking about it, all three of those could actually be combined into a single Arg::custom_parse which accepts a function that takes the arg/value currently being parsed, and returns an Option<T> where None is skip this value (i.e. parse it as a different arg), or Some(T) is "save this to the matches" it could be the value as passed in, or it could be something different entirely (i.e. a map).

This could also require a few companion methods on the matches struct that allows mutation. I'd like to expose these on a newtype wrapper PartialMatches(ArgMatches) so as not to expose these mutation functions on a regular basis. Functions could be something like PartialMatches::remove_{value,arg}, PartialMatches::add_{value,arg}, etc. It would also have all the normal ArgMatches methods provided via a facade.

@kbknapp kbknapp added T: new feature A-parsing Area: Parser's logic and needs it changed somehow. labels Feb 16, 2018
@kbknapp kbknapp added this to the v3.0 milestone Jul 22, 2018
@Zooce
Copy link

Zooce commented Jul 16, 2019

This is exactly what I'm looking for. I have a use case where I'd like to give the user the ability to abbreviate a positional argument if they want to. I could then use the custom_parse (or whatever) function to see if they did abbreviate, and if so, map it to the full argument.

@pksunkara pksunkara removed the W: 3.x label May 26, 2021
@pksunkara pksunkara removed this from the 3.0 milestone May 26, 2021
@pksunkara
Copy link
Member

Probably related #1880

@epage
Copy link
Member

epage commented Dec 9, 2021

Going to close this in favor of #2683.

@epage epage closed this as completed Dec 9, 2021
@epage epage added the S-wont-fix Status: Closed as there is no plan to fix this label Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations S-wont-fix Status: Closed as there is no plan to fix this
Projects
None yet
Development

No branches or pull requests

4 participants