New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify where and how dotted keys define tables #859
Conversation
@pelletier Can you make the same suggested change here that you suggested on #848? That way, you'll be credited with the change. @ChristianSi Once this comes together, do you want to expedite the merge? |
Co-authored-by: Thomas Pelletier <github@pelletier.codes>
Should we still address the concern in #848 (comment) (and possible solution in #848 (comment)) somehow? |
@hukkin My opinion is that the language in this PR is clear enough and there is no need for further changes. |
Agreed. A table can only be defined in one section using only one method. So writing both keys |
Asking a clarifying question. Given the follow TOML document, are the comments within it true? # Given
a = {b.c = 0}
# VALID since the keys of "b" are not entirely defined by the "b.c" reference above
a.b.z = 0
# INVALID since the keys of "a" are defined entirely by the inline table
a.c = 0
[a.d]
[[a.e]] |
@moorereason My understading is that both comments in your example document should say |
@moorereason: Yes, both your examples are invalid, like @hukkin says. # Given
a = {b.c = 0} # a is completely defined as an inline table
# INVALID since the keys of "a" are defined entirely by the inline table
a.b.z = 0
# INVALID since the keys of "a" are defined entirely by the inline table
a.c = 0
[a.d]
[[a.e]] Actually dotted keys aren't really relevant or needed for this example. Inline tables are assumed to be complete, hence, after your |
@mojombo @pradyunsg Can you review this PR and check if it's ready to merge? |
Removes and replaces language that could potentially allow dotted keys in a parent table of an existing table to inject key/value pairs into subtables of the existing table. Closes #846.
This PR replaces the previous PR #848.