You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With our strftime syntax it is possible to specify padding (zero padding %0?, spaces as padding %_?, no padding at all %-?, or the default).
This maps to three variants in the Pad enum : None, Zero and Space. That is good enough for formatting.
For parsing we currently just ignore whatever is specified as padding. We trim all whitespace, accept leading zero(s), and read a number.
There are cases where users want parsing to be forgiving (as it has always been in chrono), and others where users want the parser to be very strict.
I propose that in 0.5 we add at least one more variant to the Pad enum. That should allow the parser code to know if the users wants a forgiving parser (by not specifying anything about padding), or if he explicitly asks for none, zero or space padding.
Related issues: #1112, #1118. The PR that was merged in the 0.5 branch to be exact about whitespace exaggerates this issue, because with it the parser code now only accepts no padding or zero padding (#807).
The text was updated successfully, but these errors were encountered:
If we would add a Default variant to Pad that would mean we have to learn the formatting and parsing code what the defaults for all possible formatting fields are. That is not very elegant.
Instead we should add something like ZeroOrNone:
pubenumPad{None,Zero,Space,ZeroOrNone,}
Zero and Space would require padding, None would disallow padding, ZeroOrNone would allow optional zero padding.
Alternatively we can define Zero to allow optional padding and add a ZeroRequired variant.
That would be closer to the current behaviour. The only part that would make that a potentially breaking change on 0.4.x is the addition of an extra enum variant.
With our strftime syntax it is possible to specify padding (zero padding
%0?
, spaces as padding%_?
, no padding at all%-?
, or the default).This maps to three variants in the
Pad
enum :None
,Zero
andSpace
. That is good enough for formatting.For parsing we currently just ignore whatever is specified as padding. We trim all whitespace, accept leading zero(s), and read a number.
There are cases where users want parsing to be forgiving (as it has always been in chrono), and others where users want the parser to be very strict.
I propose that in 0.5 we add at least one more variant to the
Pad
enum. That should allow the parser code to know if the users wants a forgiving parser (by not specifying anything about padding), or if he explicitly asks for none, zero or space padding.Related issues: #1112, #1118. The PR that was merged in the 0.5 branch to be exact about whitespace exaggerates this issue, because with it the parser code now only accepts no padding or zero padding (#807).
The text was updated successfully, but these errors were encountered: