Sweet, I will open up the proposal, unless there is mass descent to this
idea.
I will call out that this WILL make implementing marshaling logic harder,
but it seems orthogonal to the desire for a vet check to prevent random
code breakage.
On Mon, 15 Mar 2021, 23:31 Ian Lance Taylor, wrote:
> I
> Hence breakage seems entirely reasonable to me, to force the user of T1
to decide how to handle it.
This feels like saying, if a customer implements an interface and that
interface adds a method, it is up to the user to decide how to handle it.
There is even a suggestion to use private method l
My apologies this is already called out in apidiff's desiderata section
under the Using an Identical Type Externally heading.
https://pkg.go.dev/golang.org/x/exp/apidiff
This means that it is already apocrypha. Is there still discussion to be
had about struct tags and marshaling, or should I open
isn't friendly towards
>>> other packages re-using the same type, but changing encoding aspects.
>>> Allowing conversions to ignore struct tags was a way to remedy that, but as
>>> you demonstrate, that's still far from ideal.
>>>
>>> So perh
When working with wire formats, serialisation, and external types, it is
useful to change the struct tags: https://play.golang.org/p/h6b6FmeDuaR.
But when the original struct has a field added, this breaks:
https://play.golang.org/p/VHmV9r2MxNt. It seems like a foregone conclusion
that we sug
