Clarify: no dotted keys or subtables into inline tables #647
Conversation
|
A problem I see here is that the text doesn't address the reverse case. It the following allowed? a.b = 1 # INVALID
a = {c = 2}Obviously, it isn't, but the text doesn't make this clear. Indeed, the wording "Once inline tables..." might suggest that dotted keys can "inject" values into inline tables as long as the inline table itself is defined later in the document. |
|
That's easy to resolve. How about if we add this? If a table is defined with dotted-key expressions, it cannot be redefined with a.b = 1 # The table `a` is defined here.
#a = {c = 2} # INVALID: This table is defined with dotted keys.
a.c = 2 # This is okay |
|
@eksortso That reads better, however, the other case should be mentioned too: #[a.b] # INVALID, since a is an immutable inline table (see below)
a = {} |
|
Perhaps something like "inline tables by definition must contain all their key/value pairs inline, including sub-tables, or else they would not be inline tables, and so, are invalid" would be to-the-point. |
That's not really a good distinction IMO, since the The point is that you cannot create a table more than once, regardless how you define it in the TOML document. In the modified example that I provide above, by rewriting I have struggled with this a bit too, when implementing my TOML parser, and what I ended up with was that internally I keep track of implicit and explicit tables. An implicit table is a table which is only used as a "path" in a dotted key syntax. For example: Here, I have to create a table "a" and a table "b". Table "a" is flagged implicit, table "b" is explicit. I'm not saying that "implicit" versus "explicit" should be wording to be used in the spec. I'm just trying to help getting clear what constructions are allowed and what are not allowed. |
|
Thanks for getting the ball rolling on this @eksortso, and for your inputs here @ChristianSi and @workingjubilee! I've posted what I had locally at #652 from a few weeks back. If no one has any concerns with that, let's merge that. If there are concerns, please voice them here and I'll close the other PR -- let's avoid splitting the discussion. :) |
Sorry, but I honestly don't know how to react to that. |
|
You got it down pat with #652, @pradyunsg, thank you. I'm closing this PR. |
|
😅 Sorry, was an unfortunately half-baked thought. |
This intends to resolve #630, i.e. it clarifies that inline tables are immutable once defined.