-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add colon_delimiter option and change default behavior #132
base: master
Are you sure you want to change the base?
Conversation
Why not just add an option called |
Good suggestion, but it seems not that easy. We might need to talk about some design.
error[E0502]: cannot borrow
|
Just pushed the changes which uses generic const, what's your thoughts? Generic const makes default behavior more subtle... |
That would become a breaking change, because Why not we just keep
|
On the other hand, if delimiter is now configurable, whether there are any usecases that wants to have a delimiter with multiple chars, for example, "==". That would require lots of refactors, I would prefer not to do this right now. |
The main concern from my side was "self.parse_str_until(&self.opt.key_value_delimiter.clone(), false)", about the perf of clone. As we could see, it needs clone to satisify the rust borrow constraint, for Have no idea, maybe it's fine, anyway, how slow it could be? |
#133
Although we did add colon(':') as key value pair separator:
#29
It's more common for user to only treat '=' as the only separator.
And add colon make some edge condition broken, .e.g, some config in .npmrc(it's ini in fact), which has ":" as part of the key.
I add an option in this PR, and change the default behavior to not treat ':' as separator.
I agree it's arguable to change default behavior, what's your opinion?