Skip to content
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

Unclear whether trailing commas are allowed in inline tables #569

Closed
ghost opened this issue Oct 6, 2018 · 4 comments · Fixed by #690
Closed

Unclear whether trailing commas are allowed in inline tables #569

ghost opened this issue Oct 6, 2018 · 4 comments · Fixed by #690
Assignees

Comments

@ghost
Copy link

ghost commented Oct 6, 2018

It is unclear from the specification whether trailing commas are allowed inside inline tables.
For example:

a = { b = 1, c = 2 , } # is this allowed ?

The section Inline Table says nothing about trailing commas, implying that they are not allowed.
However, a casual reader of the specification could reasonably assume that the same rules apply to trailing commas in arrays as in inline tables.

The ABNF definition forbids trailing commas in inline tables, but the ABNF is currently not authoritative.
I think the section Inline Table should explicitly forbid trailing commas to avoid possible confusion.

@pradyunsg
Copy link
Member

pradyunsg commented Oct 9, 2018

The section Inline Table says nothing about trailing commas, implying that they are not allowed.

Yep. Trailing commas are not allowed in Inline Tables.

ABNF is currently not authoritative.

The ABNF is authoritative and serves to clarify these ambiguities in such cases. If there are ambiguities/differences between the text and the ABNF, that's a specification bug.

I think the section Inline Table should explicitly forbid trailing commas to avoid possible confusion.

I haven't taken a look at the section yet but I have a feeling that the more "details" we add to the specification about edge cases like this, the less approachable it becomes. I am ambivalent to this specific change, but minimizing the number of minor details that we put into TOML's human readable specification is definitely a good idea IMO.

@ghost
Copy link
Author

ghost commented Oct 9, 2018

The ABNF is authoritative and serves to clarify these ambiguities in such cases.

That is great news.
However the comment in the top of the ABNF file says explicitly that the ABNF is not authoritative.

I haven't taken a look at the section yet but I have a feeling that the more "details" we add to the specification about edge cases like this, the less approachable it becomes.

I agree in principle. However I also believe it is important to be precise about what is and is not valid TOML. It is highly relevant for implementors of TOML parsers and validators, and ultimately also for TOML users.

If indeed the ABNF grammer is authoritative, I agree that is a great way to resolve these details. In that case it may be helpful to add a statement in the specification text, deferring to the ABNF grammer for precise definitions.

@pradyunsg
Copy link
Member

However the comment in the top of the ABNF file says explicitly that the ABNF is not authoritative.

Yeah; I see that now. That's mostly there because there might be nuanced issues with the ABNF that might exist that need to be "audited" - you've helpfully pointed out a few. :)

If indeed the ABNF grammer is authoritative, I agree that is a great way to resolve these details. In that case it may be helpful to add a statement in the specification text, deferring to the ABNF grammer for precise definitions.

Yeah, I think @toml-lang/core will want to do that in the lead up to a v1.0.

@pradyunsg pradyunsg added the abnf label May 13, 2019
@pradyunsg
Copy link
Member

We'd want to clarify in the specification text that trailing commas in inline tables are not permitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant