Add char type #449
Add char type #449
Conversation
Codecov Report
@@ Coverage Diff @@
## master #449 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 12 12
Lines 3724 3729 +5
=========================================
+ Hits 3724 3729 +5
Continue to review full report at Codecov.
|
|
This has become a little more complicated than originally intended. The issue arose with handling enumerations with a char type, which wouldn't want to allow single characters. So that required discriminated those cases in the lexical cast. Which led to a separate function for integral conversions and some other code cleanup that could be done as a result. which led to some tweaks to some of the validators. |
|
One remaining question: In the char conversions with single digits '0' - '9' should these be treated as the numerical equivalent or the character? treating them as numbers would be completely backwards compatible, but questionable whether that is needed or not when moving to 2.0. Not sure I have a strong preference, my use case wouldn't be impacted and enum:char are handled separately. |
|
So would 03 be the way to get the char value 3? Then 3 probably could the be char 3, as otherwise you can't get the char 3 without looking up it's numerical code? |
|
If we treated single numerical values as character ['0'-'9'] the ways to get the numerical value if that is what you wanted would be, using 3 as an example: |
|
Do you have a stronger opinion now about the best choice here, or are you still torn? |
|
My inclination is that taking it as an actual char is preferable, since otherwise it would be complicated to actually get the character '3', my only hesitancy is that it does break backwards compatibility. which should be fine if the next release is 2.0. |
|
We may make a 1.9.1, but I think we've already sailed past 1.10. The downside is I'll have to get two or three large changes in that I really want in 2.0. |
Feel free to correct me if I'm wrong, I need to compile the changelog. |
|
yeah I think there were a few changes that already broke backwards compatibility in a few circumstances, so we were definitely on the path to a 2.0 release. |
…s the actual numerical conversion using the lower level function to avoid catching exceptions internally. add a test for char options add support for char types to the lexical cast, to allow single character types that make sense, add a integral_conversion operations to simplify the conversions from string to integers and allow discrimination in a few cases with enumerations.
|
@henryiii Was there anything you wanted me to do with this or are you just waiting for a 2.0 release? |
|
I was a little indecisive about "1" being char 1 or value 1. Rereading it, I think the point that there's a way to get a number, but not a good way to get a char is reasonable enough to argue for this being best. |
Add support for a char type in the options.
This was technically supported before but in that the option type was accepted but it was always interpreted as an int, which is not necessarily what is desired. The added conversion interprets single character strings as the character, and otherwise defaults to a numerical conversion.
This issue came up a couple times in our usage, when character inputs unexpectedly produced errors when trying to define an option for a separation character or delimiter.