Investigate how to best get rid of slice pointers

[nscuro]

Currently, we're using slice pointers (e.g. *[]string) to work around a limitation of encoding/xml.

It works, but it's not pretty. This is painfully obvious when trying to iterate over elements of those slices and having to dereference and nil check all the time. It'd be great if we could just have normal slices instead.

Most likely, we'll have to introduce a lot more custom (de-)serialization code specific to the XML format to make this work.

[ragaskar]

Is it known if anyone is actively working on this?

If not, and I have some spare time (in short supply for me at the moment, but you never know...) I might take a shot at fixing this, since as a user (thanks for this lib, by the way!!!!) I definitely feel the rough edges caused by these pointers. Just don't want to duplicate efforts if someone else is already working on this problem 😁 .

I imagine any extra existing context would be helpful too (e.g., "I tried doing it but it was harder than I thought because X, Y or Z").

[nscuro]

I don't have much extra context here. The main issue is that simply switching to non-pointer slices makes the XML serialization extremely noisy, and potentially invalid according to the spec. This issue is detailed in the StackOverflow discussion I linked in the issue description.

The only alternative I can come up with is to implement MarshalXML for every single type in the code base. Which is a lot of code, and will drastically increase maintenance effort going forward.

[ragaskar]

Thanks, that's a helpful starting point. Looking through that I guess my rough understanding is that XML un-marshalling will only "omitempty" slices if they are pointers (and thus actually nil), and there's a desire to avoid emitting noisy XML -- XML with a bunch of empty tags (makes sense). I guess I would hope for a magic bullet of shared behavior (shared unmarshall code via struct composition?) that could define this in one place. Anyways, if I get a chance to tinker I'll try to share anything I learn on this issue.

[ragaskar]

Thought about this a little bit, and one thing stopping me from testing out some implementations: how would the library approach the breaking change this introduces?

When I look at the code I've written that would "benefit" from this, it would all need to be rewritten, so as a user I would want a long deprecation period.

Would one opt-in at instantiation time (with a flag/diff struct) to get the pointer-free structure? It seems like it would be potentially a massive pain to maintain parallel structures internally.

[nscuro]

how would the library approach the breaking change this introduces?

We abide to SemVer and release that change under a new major version. We can maintain multiple major versions if required, but I don't see a need to maintain two separate implementations within the same version.