Conversation
ChristianSi
left a comment
ChristianSi
left a comment
There was a problem hiding this comment.
This may ultimately be better suited for a FAQ or rationale page, but since TOML does not yet have one, a short explanation in the spec itself seems appropriate enough. However, I’d be a bit more explicit about the underlying reasoning; see my suggested change.
| You cannot use multi-line strings to define quoted keys. | ||
|
|
||
| TOML tables are intended to map to hash tables or dictionaries, as a consequence | ||
| empty quoted keys are allowed (though discouraged). A bare key must be |
There was a problem hiding this comment.
The rationale feels a bit underspecified. Many languages and data structures that have hash tables or dictionaries also allow numbers, booleans, and other non-string values as keys, but TOML keys are intentionally more restricted than that. So, to prevent further possible confusion, I’d suggest making the rationale a bit more explicit, perhaps along these lines:
TOML tables are intended to map to hash tables or dictionaries, which commonly permit empty string keys. For that reason, empty quoted keys are allowed, though discouraged. A bare key must be non-empty.
There was a problem hiding this comment.
How about:
TOML tables correspond to hash tables or dictionaries which usually permit any string value. For that reason empty quoted keys are allowed, though discouraged. A bare key must be non-empty.
"intended to map to" → "correspond to" as it seems a bit less of a mouthful.
"commonly permit empty string keys" → "usually permit any string value" as that's a bit more general.
There was a problem hiding this comment.
Okay, changed it with hash tables or dictionaries → hash tables (also known as dictionaries) because on re-reading the "or" could be interpreted to mean "one or the other" rather than "also known as".
TOML allows empty (quoted) keys: "" = 123 Over the years I've seen a number of people express surprise that it's allowed. The reason it's allowed is because TOML tables are intended to map to hash tables/dictionaries in programming languages, and they allow empty keys. So TOML does too. You can still argue that it's a mistake to allow it in TOML, but we can't change that now and this at least clarifies the thinking behind why it's allowed.
This comment was marked as resolved.
This comment was marked as resolved.
|
@cyyynthia: For just one sentence added, a |
|
Personally I think the "why" of these sort of things should be part of the main specification text. Over the years I've found that knowing why something is the way it is hugely helps actually understanding and remembering things. Otherwise it just become rote memorisation and I kind of suck at that. Within reason, of course. A potential FAQ could expand on some of the things in the specification. But I do think it's helpful to explain the why, when it might be useful, as concise as possible, regardless of whether we have a FAQ or not. I would certainly not be in favour of footnotes or |
Is there evidence for this as an explanation? Or is it a story we are retro-fitting ten years later? If it were a good explanation, wouldn't non-string keys also be allowed? The relevant phrase was I think introduced at #387, which nominally was just moving text around. I don't find any discussion of whether or not to allow empty strings - perhaps something exists elsewhere? - so it is hard at this distance to say what the reasoning was. FWIW: no explanation was offered at #432, which was nearly contemporary. |
|
It's in the text already: "Tables (also known as hash tables or dictionaries)". Older versions are even more explicit: "TOML is designed to map unambiguously to a hash table". |
|
The question was not: is TOML designed to map to a hash table? I agree that it is. But this would hold regardless of whether empty strings were allowed as keys. The question was more: is this either a historically accurate or currently useful explanation for why empty strings should be allowed as keys? I find it unnecessarily involved, eg as both I and - I now see - ChristianSi have experienced, talk of hash tables raises questions in reader minds about non-string keys. To my mind a simpler explanation is just: empty strings are allowed because an empty string is a perfectly good string and there was no compelling reason to make an exception for it. Whether that deserves a sentence in the spec is unclear to me. |
|
@dimbleby: I agree – that’s a perfectly plausible explanation, and "TOML keys are conceptually strings" is a simpler way to put it than "TOML tables are conceptually hash tables whose keys are arbitrary strings." Both arrive at the same endpoint, but the detour through hash tables seems unnecessary. |
4 participants
TOML allows empty (quoted) keys:
Over the years I've seen a number of people express surprise that it's allowed.
The reason it's allowed is because TOML tables are intended to map to hash tables/dictionaries in programming languages, and they allow empty keys. So TOML does too.
You can still argue that it's a mistake to allow it in TOML, but we can't change that now and this at least clarifies the thinking behind why it's allowed.