If we consider sigfigs, then isn't 100 and 100. two different numbers given one has a single significant digit and the other has 3? For 101 and 101. it doesn't matter because both have 3 significant digits. Then again, one may argue that it is better to write 1e2 and 1.00e2 instead of 100 and 100.. It also avoids the weirdness of the double period if the number with a dot ends a sentence.
On a personal level, I also don't like ending a number with a . because my brain immediately parses it as a sentence ender and it interrupts my reading flow.
It's just not wanting to keep track of more rules. If you've only ever used languages where a leading decimal point is allowed, it's a pain point to suddenly have to remember that it isn't here, and for no obviously intuitive reason.
It's about wanting to avoid unnecessary conceptual friction. Not lazy keyboard usage.
(Heck, your second example uses an extra keystroke. And it's perfectly readable to me, based on the languages I use.)
There's something to be said for being flexible in your inputs when they are non-ambiguous. Particularly when dealing with files written by hand.
There's no virtue in imposing overly strict syntax when it serves no human purpose. That's trying to alter people to fit machines, rather than altering machines to fit people.
Yeah, and we could easily say that any property value without a comma, closing bracket, or closing brace; that doesn't follow the format for numeric literals; and isn't the literal value 'true' or 'false' doesn't need to be quoted when part of a value and will implicitly be a string. This adds no ambiguity and some people are used to writing their string literals without any extra quotes, why add the extra cognitive load of having to remember to use quotes? Wouldn't it be nice to write `user: { type: admin, name: Bob }`?
This seems like exactly how we ended up with YAML-and-the-kitchen-sink.
For a spec like this, things should need a better justification than that. Everything starts at -100 points. How does this feature justify the additional complexity in the spec, to the users, and to the people trying to implement this? How does it justify increasing the opportunity for creating subtly incompatible parsers?
Or, if a goal of JSON is not to be simple and interoperable, then I fail to see how it's not just YAML but 5 or 10 years behind the curve, so we may as well skip a bunch of hassle and move to YAML and start fixing the bugs we've got there rather than creating new ones here.
I don't know what to tell you, you seem to be taking a black-or-white approach here of extremes. Like anything that isn't limited to exactly one way of expressing it is a slippery slope to YAML. It's not.
JSON5 is literally exactly JavaScript notation, which tons of people are familiar with. On the other hand, I don't know any programming languages that use strings without quotes or delimiters. (And of course, their existing in YAML is widely recognized as a major source of confusion.)
And in your example, there isn't parsing ambiguity but there would be change ambiguity when you alter abc (without quotes) to 123, because it changes its type.
I'm not aware of any change-ambiguity situations in JavaScript/JSON5 like that? In Python 5 and 5. are different types, but not in JavaScript or JSON.
Trailing to signal a floating point seems like to niche of a use case to me. Generally it's best to treat every JSON number literal as a 64-bit float anyway for the sake of interoperability.
It became quite normal for me to write 0.3 and read it as “point three”. I do agree that the English language makes it less awkward to just skip the zero. It leaves very little room for confusion.
It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”.
Arguably, if there's ambivalence about numbers or other core structures or doubt about the intent, the correct thing to do is to return an error and not try to guess. The point of an error bubbling up is asking for clarity from the end-user, while guessing will lead to random results in ways that can not be detected or corrected anymore later on in the process.
I think Postel's law was intended to apply to alternative implementations of machine-level protocols.
That's not to say that I don't agree that it might be better if JSON implementations would allow trailing commas, which is unlikely to lead to semantic ambiguities. That's too late now though, unless a new JSON to rule them all would appear and we would all agree on that new spec.
I don't think Postel's Law was necessarily a bad idea, in its time and context. However it seems to have fallen into usage as an argument-ender. This RFC is a useful antidote to that.
Well what's more readable, .8675309 that is understood to have an implicit zero, or the parser giving up and unexpectedly making it a string? Maybe it's not your preference but I can't see any problem with making this more robust. The trailing one is strange to me but leaving off a leading zero isn't unusual at all for written numbers in my experience.
> Well what's more readable, .8675309 that is understood to have an implicit zero
Is it universally understood? I think it's a US / English thing. In my country I've never seen numbers written in this way and many people would not "parse" it mentally as 0.8675309
What an extreme reaction. Many people would not be able to parse it since they've never seen a number written in this way, but you immediately write them off as assholes. Wow.
It will look funny to many people but they will be able to interpret it. Remember that this thread is in the context of whether to be strict or relaxed in a specific file syntax for files intended to be authored by humans.
> It will look funny to many people but they will be able to interpret it.
You're still approaching this with the background knowledge of what this is. If you've never seen this, you can only guess, and there are a couple of options.
I've been terminally online for the better part of the last 2 decades, yet I've seen this way of writing for the first time only ~5 year ago or so, and I still remember simply not knowing what it is. The first reaction is that it's simply a typo - the author mistyped - the dot should have been a digit or perhaps not be there at all.
For people who grew up in countries where comma is the decimal separator (and dot the thousands grouping separator), this is highly unintuitive, because it would seem much more likely to be a misplaced punctuation mark.
It might be moderately intuitive to English native speakers because of oral usage like “point one three eight”, but that’s also not a thing in many other languages.
- "a gallon". Not purely US thing but almost. It can be anything from 3.8 to 4.4 liters, depending mostly on what are you measuring.
- writing digits. Is it "1", is it "7", is it "i", is it "l"? Why do it to yourself, while their printed fonts are pretty much the same as everywhere else...
IMO the implicit zero is just as much an issue in regular written form. The period could be overlooked quite easily, but seeing a leading 0, one will know what’s really going on.
How could the parser see it as a string? This is not YAML and JSON5 still requires quotation marks.
On the other hand:
> leadingDecimalPoint: .8675309
This is just lazy. Can we discuss in depth how much time you saved by skipping the “0” in favor of lesser readability?
> andTrailing: 8675309.,
This doesn’t mean anything to me.