I never understood leading dot until I understood that native speakers indeed say ".3" (point three).

Trailing makes it a floating point type instead of an integer

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.

Right, you guys say like “naught point three”… sounds just as weird to us as ours does to you.

Still… I can be required to put a zero in, read 0.3, and still think “that’s point three”.

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.

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

I have never encountered an adult human being who would not be able to “parse” this mentally and come up with the correct value. If I did, I wouldn’t associate with them voluntarily as they would likely be an asshole, spending all their time bikeshedding and making everyone else miserable due to their inability to cope with someone not following their unwritten “rules”.

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.

Stripping zero is not a common practice. You are clearly speaking of your own bubble here.

For most of the world that is even more ridiculous than using dot as decimal space separator or writing dates with month not in the middle place.

Even Americans I work with don't write it like that when doing quick draft discussion, as they know it's confusing to others.

It’s not about whether people normally write it that way. In the overall context of the thread it’s whether they ever write it that way.

From my perspective no one does. Ever.

I only know it's a thing because I watched some math-related edu shows. Didn't even see that when I briefly worked in US.

> even more ridiculous than ... writing dates with month not in the middle place

Come on, let's be fair—nothing else will ever be as ridiculous as that!

I could maybe throw into the contest:

- "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...

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.

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.

It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”.

Reference: Postel’s Law

https://www.laws-of-software.com/laws/postel/

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.

Postel's Law was a bad idea.

https://datatracker.ietf.org/doc/html/draft-thomson-postel-w...

'"bug for bug" compatible'

Good reference! Turns out this internet draft has been turned into an official, informational RFC:

https://datatracker.ietf.org/doc/html/rfc9413

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.

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 has nothing to do with laziness in typing.

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.)

I think if we start applying that rationale we could skip a lot of steps and just move everything over to YAML.

No because YAML is full of ambiguity.

JSON5 is not.

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.