Support encoding comments in toml tag #97
Conversation
This implements the suggestion in the referenced issue. I wouldn't say this is a particularly nuanced way to support encoding comments, but it was easy to implement and I wanted to see if people would be receptive to it.
|
This branch works great for encoding. However, decoding fails on all fields containing a comment. |
Adding comment support to struct tags broke decoding for those fields. This commit fixes that bug, along with the failing test in the previous commit.
|
@DevelopSMM thanks for the feedback. I've added a few commits that fix this problem. I didn't bother rebasing or merging with tip, but would be happy to do so if there was interest in merging this branch. |
|
I lean towards not putting more things into the struct tags. |
|
I don't think we should go down the road of encoding arbitrary comments in struct tags. |
|
Absolutely makes sense, but do you have any solutions on how to handle comments then? When working with config files it's nice to be able to document inline what each option is supposed to do. |
|
Comments are fully supported when decoding TOML. This PR is about encoding comments. |
|
Yeah, this was never a good idea. I think it's useful to be able to generate TOML with comments, (say for outputting default config files) but there's gotta be a better way. Maybe text/template. |
Implements the feature suggested in #75. I'm not sure this is actually a good idea, but thought I'd share anyway.
A possible issue with this is that people who use comments might experience breakage if later on the library implements an option that matches their exact comment. That seems like a pretty remote possibility to me, since comments are usually partial sentences.
Another way to accomplish encoding comments would be the way encoding/xml does it, but I'm not particularly fond of that approach either tbh.