You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Clarify that comments and newlines are allowed before commas in arrays.
I read this as comments are allowed before commas in array, such as these two examples:
obj= ["a value", "second value"# Here is a comment, "last value"]obj2= [
"a value",
"second value"# Here is a comment,"last value"
]
I presume this is not the case? But the wording in the release note threw me off for a while - unless it is allowed, which seams weird as it doesn't make sense to have a comment mid-definition of something (meaning, after the defining statement but before the end of that statement).
The reason will be displayed to describe this comment to others. Learn more.
It was thought that newlines after comments were obvious. A comment always extends to the end of the line. The commas that the change refers to come after the newline, like this:
obj2 = [
"a value"
,"second value"# Here is a comment
,"last value"
]
Originally the changelog said "comments with newlines". It was changed because newlines alone, without comments, are also permitted before commas in arrays. So both comments with their newlines, and newlines on their own, are allowed before commas in arrays.
The reason will be displayed to describe this comment to others. Learn more.
Newlines after comments are obvious to me too, it's the placement of the comma that boggled me.
I did not see any wording prohibiting the above example I showed, which is essentially what you showed @eksortso - but with a different placement of the comma.
Which makes parsing a living nightmare if it's a valid option. Although treating , as another new-line object would be a possible but would feel hacky.
The more I try to parse TOML (for fun), the more I realize that the language emphasizes easy to read over easy to ... parse with machines.
Depending on what is and was isn't allowed, I would probably strengthen the release note wording, making sure that what I wrote is not mistaken as allowed if it's not supposed to be.
The reason will be displayed to describe this comment to others. Learn more.
It's true that readability is more important than easy parsing. But we did spell out the fine details in the ABNF document. Make your parser equivalent to that, and you're good to go.
The reason will be displayed to describe this comment to others. Learn more.
@Torxed You do realize that every comment extends to the end of the line, don't you? You can't place a comma AFTER a comment WITHIN the same line, since it will simple become a part of the comment.
But now you can place a comma after a comment in the NEXT line, as @eksortso shows in his example. That wasn't allowed until this release, which was likely an accident and never a deliberate design decision.
The reason will be displayed to describe this comment to others. Learn more.
@ChristianSi I get that from reading https://toml.io/en/v1.0.0-rc.3#comment, I just felt that the commit message added double standards to where and how the comment could be placed/written. It was a very minor remark, I did not mean to cause a lot of ruckus.
The reason will be displayed to describe this comment to others. Learn more.
No problem, we appreciate the feedback. This helps us catch rough edges that we missed or hadn't noticed before.
The commit messages are part of the standard's development process, but they're not part of the standard itself. Those messages can afford to be a little imprecise, so long as we get the details straight on toml.io and in toml.md and toml.abnf. Likewise, the changelog provides an "at-a-glance" view of changes to a spec, but for the details, check the actual specification documents. If those are imprecise or unclear, feel free to suggest changes.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read this as comments are allowed before commas in array, such as these two examples:
I presume this is not the case? But the wording in the release note threw me off for a while - unless it is allowed, which seams weird as it doesn't make sense to have a comment mid-definition of something (meaning, after the defining statement but before the end of that statement).
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was thought that newlines after comments were obvious. A comment always extends to the end of the line. The commas that the change refers to come after the newline, like this:
Originally the changelog said "comments with newlines". It was changed because newlines alone, without comments, are also permitted before commas in arrays. So both comments with their newlines, and newlines on their own, are allowed before commas in arrays.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newlines after comments are obvious to me too, it's the placement of the comma that boggled me.
I did not see any wording prohibiting the above example I showed, which is essentially what you showed @eksortso - but with a different placement of the comma.
Which makes parsing a living nightmare if it's a valid option. Although treating
,
as another new-line object would be a possible but would feel hacky.The more I try to parse TOML (for fun), the more I realize that the language emphasizes
easy to read
overeasy to ... parse with machines
.Depending on what is and was isn't allowed, I would probably strengthen the release note wording, making sure that what I wrote is not mistaken as allowed if it's not supposed to be.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true that readability is more important than easy parsing. But we did spell out the fine details in the ABNF document. Make your parser equivalent to that, and you're good to go.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Torxed You do realize that every comment extends to the end of the line, don't you? You can't place a comma AFTER a comment WITHIN the same line, since it will simple become a part of the comment.
But now you can place a comma after a comment in the NEXT line, as @eksortso shows in his example. That wasn't allowed until this release, which was likely an accident and never a deliberate design decision.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ChristianSi I get that from reading https://toml.io/en/v1.0.0-rc.3#comment, I just felt that the commit message added double standards to where and how the comment could be placed/written. It was a very minor remark, I did not mean to cause a lot of ruckus.
3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, we appreciate the feedback. This helps us catch rough edges that we missed or hadn't noticed before.
The commit messages are part of the standard's development process, but they're not part of the standard itself. Those messages can afford to be a little imprecise, so long as we get the details straight on toml.io and in
toml.md
andtoml.abnf
. Likewise, the changelog provides an "at-a-glance" view of changes to a spec, but for the details, check the actual specification documents. If those are imprecise or unclear, feel free to suggest changes.3b66213
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eksortso Will do! Cheers for the quick responses.