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.
I also agree that the rationale is purely informational and I have mixed feelings about it being part of the spec document. It's at the same time valuable info, and at the same time noise that doesn't really have normative value. Perhaps a |
|
@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 |
3 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.