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

Suggestion: EOD tag #429

Closed
mbakke opened this issue Aug 21, 2016 · 4 comments
Closed

Suggestion: EOD tag #429

mbakke opened this issue Aug 21, 2016 · 4 comments

Comments

@mbakke
Copy link

mbakke commented Aug 21, 2016

Currently there is no way to verify that a TOML document is "complete". Having a closing tag would allow parsers to reject TOML that is only partially read, similar to when JSON is missing the closing bracket.

This is useful when sending TOML over a network, for example.

@veeg
Copy link

veeg commented Aug 21, 2016

TOML is not a serialization format. Adding any logic that reduces the human-friendly configuration format (ref: @mojombo comment) is ill-advised in my honest opinion.

@TheElectronWill
Copy link
Contributor

When sending TOML over a network, you usually send the document's length first. So no need for an "EOD" tag in that case.

@mbakke
Copy link
Author

mbakke commented Aug 21, 2016

Fair points. I guess some network transports can take care of validation. From the linked issue, there seems to be some expectation that TOML can be used as a general serialization format. Perhaps a "strict mode" that requires opening and closing tags could work, but I agree that it would be neither obvious nor minimal to require it in normal use.

@mojombo
Copy link
Member

mojombo commented Jan 3, 2017

I think @TheElectronWill's arguments against a closing tag are on point, and I don't see a compelling need for this. Thanks for the suggestion anyhow!

@mojombo mojombo closed this as completed Jan 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants