Is your feature request related to a problem? Please describe.
Currently the implementation doesn't allow for '=' in the value of a key value pair. Passing certain values (e.g. a connection string) is not possible without implementing a custom PairDeconstructor. This behaviour seems to be intended (see here and the corresponding tests) but it differs from the default option parsing where the value may contain = (see here and here).
Describe the solution you'd like
Ideally the default should be the same as for regular options (which would also mean : is a valid separator, i think?). I couldn't find a reasoning for this behaviour (the idea might've been to fail hard on potential misinputs?).
Another possible solution could be to only allow this inside quoted strings or escaped (\=) but that'd be a more complex solution.
Describe alternatives you've considered
Current workaround is implementing a custom PairDeconstructor.
Additional context
If this is a change that is wanted i can provide a PR but we should maybe decide on what the behaviour should be before ("just allow ="? - "allow quoted"? - "align to options parsing, allowing for : and = as separator"? - other solutions)
Is your feature request related to a problem? Please describe.
Currently the implementation doesn't allow for '=' in the value of a key value pair. Passing certain values (e.g. a connection string) is not possible without implementing a custom
PairDeconstructor. This behaviour seems to be intended (see here and the corresponding tests) but it differs from the default option parsing where the value may contain=(see here and here).Describe the solution you'd like
Ideally the default should be the same as for regular options (which would also mean
:is a valid separator, i think?). I couldn't find a reasoning for this behaviour (the idea might've been to fail hard on potential misinputs?).Another possible solution could be to only allow this inside quoted strings or escaped (
\=) but that'd be a more complex solution.Describe alternatives you've considered
Current workaround is implementing a custom
PairDeconstructor.Additional context
If this is a change that is wanted i can provide a PR but we should maybe decide on what the behaviour should be before ("just allow
="? - "allow quoted"? - "align to options parsing, allowing for:and=as separator"? - other solutions)