• You can use limited html like blockquote in comments, WYSIWYG editor coming soon...

    What is it you don't like about struct tags?

    IMO they mix up separate concerns, use an ad-hoc syntax and end up a mess in complex apps, it's like a whole other language stuffed into a string and defined by random lib authors. A field might have json, xml, db tags all in one string.

    They're pragmatic in a way, and in small doses useful, but I just think they're adding unstructured informal data attributes to structs and fields which is better specified formally in code. Take for example an xml field, it might over time have name,attr,chardata,innerxml,omitempty,cdata attributes added (and more in future), and then on top of that is piled any json representation and the db representation and whatever other dsl library authors choose to require in future.

    I would prefer instead that types define functions to Marshal/Unmarshal, and that be the standard way to get data in and out of the type, it's clearer and extensible - when a new data format is required just write another function. So I avoid struct tags myself and use this approach for database mapping, and am much happier with it. By the time you're adding things like omitempty for xml it's just so much better if the code itself specifies this with a simple if condition in a function mapping from struct to xml.

    The comments as directives I assume you mean things like the build tags and generate directives? I like what they enable you to do but I'm not a fan of having those in comments indeed.

    Yes I think those are just in comments because they didn't want to change the language spec, but really something like generate should be clearly specified in the language rather than hidden in magic comments.