Minor According to the ABNF an optional 'L'/'l' character MAY be included. I was asked why this was and failed to give an answer. Dear I ask why we allow this whereas we don't make any distinction that way for the other integer types?We already allow for upscaling to a bigger type, why couldn't any integer number be just specified using its digits full well knowing that if more then 15 digits are required it has to be an int64 number ?
Mmm, not sure how I've missed the fact the 'L' is optional. Leaves the question why anybody would add it. I suppose we can close this then with no further action.
Updated the issue after, based on previous comments, realizing the 'L'/'l' is optional.
| Field | Original Value | New Value |
|---|---|---|
| Proposal | Remove the trailing 'L' character for int64 numbers. | Remove the optional trailing 'L'/'l' character for int64 numbers. |
| Description | According to the ABNF we need to append the capital 'L' character to an int64 integer whereas all the other integer types simply allow for more digits to be returned. Dear I ask why? We already allow for upscaling to a bigger type, why couldn't any integer number be just specified using its digits full well knowing that if more then 15 digits are required (and even with certain 15 digit numbers) an int64 number is required? | According to the ABNF an optional 'L'/'l' character MAY be included. I was asked why this was and failed to give an answer. Dear I ask why we allow this whereas we don't make any distinction that way for the other integer types?We already allow for upscaling to a bigger type, why couldn't any integer number be just specified using its digits full well knowing that if more then 15 digits are required it has to be an int64 number ? |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| Summary | Can we get rid of the trailing 'L' for int64 numbers | Can we get rid of the optional trailing 'L'/'l' for int64 numbers |
In V2 and V3 the "L"/"l", and equivalently the "D"/"d" for doubles, "F"/"f" for floats, and "M"/"m" for decimals was NOT optional.
Correct, also in the contributed starter documents it wasn't optional, and I can't find a Jira ticket to make them optional so that's probably a typo or wrong refactoring, propagating the optionality from the nanInfinity rule to the xxxBody rules.
On the other hand: as we now forbid function overloads that only differ in sub-types within the type families Integer and Float, so I see no situation where we'd have to "disambiguate" identical numeric values according to the representing type.
So I think we can at least get rid of the "d", "f", and "l" suffixes.
I also doubt the usefulness of function overloads for Integer and Float where the Float overload produces different results than the Integer overload for integer numbers.
My only concern with removing them fully is backwards compatibility. Making them optional seems to give the best of both worlds.
There doesn't seem to be a reason for having the 'l' or 'L' to indicate we are dealing with a 64-bit integer value. Also we are no longer allowing function overloading within the same type family so it is, presuming it was, no longer required to choose the appropriate override of a function either. The same applies to the 'f'/'F', 'd'/'D' and 'm'/'M' qualifiers indicating single, double and decimal values respectively. The proposal is updated to include the removal of those as well.
| Proposal | Remove the optional trailing 'L'/'l' character for int64 numbers. | Remove the optional trailing 'l'/'L', 'f'/'F', 'd'/'D' and 'm'/'M' qualifier for int64, single, double and decimal numbers respectively. |
| Fix Version/s | V4.0_WD01 [ 10247 ] | |
| Affects Version/s | V4.0_WD01 [ 10247 ] | |
| Environment | [Proposed] | [Resolved] |
| Status | New [ 10000 ] | Open [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Assignee | Ralf Handl [ ralfhandl ] |
| Environment | [Resolved] | [Applied] |
| Status | Resolved [ 5 ] | Applied [ 10002 ] |
| Resolution |
Accepted: https://www.oasis-open.org/committees/download.php/49055/odata-meeting-35_on-20130502-minutes.html#odata-341 |
|
| Status | Applied [ 10002 ] | Closed [ 6 ] |
| Assignee | Ralf Handl [ ralfhandl ] | Ralf Handl [ handl ] |
Is there a typo where more should read mere (meaning solely, only?) in: "[...]whereas all the other integer types simply allow for more digits to be returned[...]"?
Two things from the ABNF:
1. Let's all remember again, the case insensitive nature of ABNF (i.e. outside the "single quote reservations" of our extended usage):
int64 = int64Body [ "L" ]
int64Body = [ sign ] 1*19DIGIT ; numbers in the range from -9223372036854775808 to 9223372036854775807
the two lines cited from current ABNF (svn revision 231) have a double quote enclosed L which may well be a lowercase letter l.
2. And also, that this postfix letter (L or l) as it is placed inside square brackets is thus optional.