Re: [go-nuts] struct conversion, new fields, and incompatibility

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

Re: [go-nuts] struct conversion, new fields, and incompatibility

It may be worth noting that we already have a vet check for composite literals that verifies that if a composite literal is used with a struct defined in a different package, then the fields are explicitly named. This check means that adding fields to a struct will never break composite literals i

Re: [go-nuts] struct conversion, new fields, and incompatibility

Thanks for the clarification, and I agree completely. There are plenty of cases in the Go standard library where there is a public struct for bundling state, and I don't see adding a new member (whether it's private or public) as a breaking change. Nobody's going to attempt to mirror the entir

Re: [go-nuts] struct conversion, new fields, and incompatibility

I don’t think you can separate the two - it seems the OP purpose of using the struct conversion is to facilitate a different serialization format. This is a place where Gos convenience (struct tags) is running into explicitness. The struct conversion is nothing more than a magic copy. Make this

Re: [go-nuts] struct conversion, new fields, and incompatibility

On Fri, Mar 12, 2021 at 10:16 AM Brian Candler wrote: > I can see two separate things under discussion - compatibility of struct > types for conversion, and backwards-compatibility of serialization [JSON? > Protobuf?] > Backwards-compatibility of serialization is a red herring. It is off-topic a

Re: [go-nuts] struct conversion, new fields, and incompatibility

I think it's clear that *any* change to an interface - including adding or removing methods, or changing the arguments or return types of any method - must be a breaking change. - *Adding* a method to an interface means that a concrete type which implemented the interface before, won't satisfy

Re: [go-nuts] struct conversion, new fields, and incompatibility

> 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

Re: [go-nuts] struct conversion, new fields, and incompatibility

Maybe the argument goes something like this: * package P exports a struct type T1 * package Q deals with values of type T1 * package Q wants to serialize objects of type T1, but T1 doesn't have the desired set of tags; so it defines a new type T2 which is the same as T1 but with different tags *

Re: [go-nuts] struct conversion, new fields, and incompatibility

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

Re: [go-nuts] struct conversion, new fields, and incompatibility

On Friday, 12 March 2021 at 06:56:46 UTC axel.wa...@googlemail.com wrote: > On Fri, Mar 12, 2021 at 3:26 AM Robert Engels > wrote: > >> I must be dense on this. I have no idea why there is any use of struct >> tags or JSON marshaling in the sample code. >> > > To demonstrate why converting betw

Re: [go-nuts] struct conversion, new fields, and incompatibility

Nobody seems in favour of making this a "technically" breaking change, like changing the value of a string constant, though I think there is an argument. Does it seem reasonable to add a vet lint for this type of struct type conversion? Or is more discussion warranted? I am looking to eventually d

Re: [go-nuts] struct conversion, new fields, and incompatibility

On Fri, Mar 12, 2021 at 3:26 AM Robert Engels wrote: > I must be dense on this. I have no idea why there is any use of struct > tags or JSON marshaling in the sample code. > To demonstrate why converting between different struct types is useful. If you want take an struct existing type (defined

Re: [go-nuts] struct conversion, new fields, and incompatibility

I must be dense on this. I have no idea why there is any use of struct tags or JSON marshaling in the sample code. It will fail without any of that. > On Mar 11, 2021, at 5:28 PM, Axel Wagner > wrote: > >  > That seems unrelated to this thread. If you add a field to a proto-message > and tr

Re: [go-nuts] struct conversion, new fields, and incompatibility

That seems unrelated to this thread. If you add a field to a proto-message and try to do the same struct-conversion Colin mentions, you will run into exactly the same problem. We are talking about language facilities here, not third party code generators. On Thu, Mar 11, 2021 at 11:48 PM Robert En

Re: [go-nuts] struct conversion, new fields, and incompatibility

If you use protobufs and the current guidelines you can always add new fields. > On Mar 11, 2021, at 12:43 PM, 'Axel Wagner' via golang-nuts > wrote: > >  > Hi, > > in some sense, every change to an exported symbol is a breaking change. So a > straight-forward "does this change have the pot

Re: [go-nuts] struct conversion, new fields, and incompatibility

Hi, in some sense, every change to an exported symbol is a breaking change . So a straight-forward "does this change have the potential to break a reverse dependency" is simply not the best way to look at compatibility. We nee

[go-nuts] struct conversion, new fields, and incompatibility

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