Open ECUST-XX opened 1 year ago
Just to be clear, I think you are proposing a new function MarshalIndentShortForm
. That will be like MarshalIndent
, but a tag with no contents will use a self-closing tag. Is that about right?
Just to be clear, I think you are proposing a new function
MarshalIndentShortForm
. That will be likeMarshalIndent
, but a tag with no contents will use a self-closing tag. Is that about right?
Yes. That's right.
What is the cost of using a self-closing tag wherever it is allowed?
@adonovan Cost in terms of what? Can you elaborate?
tnypxl: Cost in terms of what? Can you elaborate?
I meant all kinds of costs. Obviously any change has the potential to cause spurious failures in existing overly-specific tests, but are there more substantial reasons why not to simply enable it always? The output would be more compact, which seems like a good thing.
@adonovan Thanks for the clarification. I do agree with your last point. I am running into this issue while researching ways to build a XML config generator.
Without having looked into the current std lib implemtantion, I imagine an always-on approach would break some tests that expect a closing tag from empty elements. I'd be interested in a struct field tag option (e.g, closeempty
or selfclose
) that lets me decide on a field by field basis. But I imagine for large complex XML trees, that isn't ideal either.
We have a small change that implements the selfclosing
option to the xml
struct tag here:
https://github.com/nbio/xml/pull/10
Happy to turn this into a formal proposal + CL if folks are interested.
Having a field based struct tag would allow us to decide whether to use self closing tags per field. Personally I would prefer to see your approach as proposal. @ydnar
See https://github.com/golang/go/issues/69273 for an alternate proposal.
Goals
Add an option, to support marshal a self-closing tag xml struct in short-form mode which has empty content.
In xml standard, a self-closing tag is permitted. https://www.w3.org/TR/xml/#sec-starttags
Definitions
Related questions
#21399