Create slice/map/string fields without pointers (for optional fields)

[v-byte-cpu]

Default value for slice/map is nil. So slice/map field will not be serialized if it is not initialized.

I mean from serialization point of view these two structs are the same:

struct {
  GroupKey *[]string `json:"group_key,omitempty"`
}

struct {
  GroupKey []string `json:"group_key,omitempty"`
}

The later version is more convenient to work with..

https://play.golang.org/p/0c0nVaoOPNK

Also the same applies to string type with omitempty json tag.

Pointer to interface *interface{} struct fields are also useless.

[yazver]

That would be good.

[mitar]

Also the same applies to string type

Why it applies also to string?

[v-byte-cpu]

@mitar https://play.golang.org/p/0c0nVaoOPNK here you can look at 33-42 lines for small example

[mitar]

Sure, but how would you know for strings if field has been provided and is empty string vs. it has not been provided at all?

[v-byte-cpu]

It makes sense. Maybe then it is better to use x-go-type extended property explicitly for your use case ? Nevertheless I suppose that most programmers almost always use simple string fields for structs (string field with omitempty tag) and your use case is very data specific.

[mitar]

I mean, I completely agree that those pointers seem to be more or less unnecessary, in almost all cases. And pain to work with. But then I also hate when in grpc/protobuf I cannot know if value was provided or not for zero values. Maybe something like that would be even better:

struct {
    GroupKey string `json:"group_key,omitempty"`
    GroupKeyProvided bool `json:-`
}

[ckarenz]

It should be up to the application to decide whether a missing value is equivalent to a zero value. I'd like to propose a solution that works for both cases. The nullable field should control indirection.

Option 1: Binary nullable (true, false)

This is my preference. Missing/false are treated identically. The default value for nullable is false per the OpenAPI 3 spec.

• required && nullable -> Foo *string `json:"foo"`
• required && !nullable -> Foo string `json:"foo"`
• !required && nullable -> Foo *string `json:"foo,omitempty"`
• !required && !nullable -> Foo string `json:"foo,omitempty"`

Option 2: Ternary nullable (true, false, missing)

Same as option 1, but when absent nullable defaults to `!required (nullable if not required non-nullable if required). This maintains current default behavior as of this writing while still allowing explicit override.

---

I'm happy to contribute a change for either approach.

[v-byte-cpu]

I think the first option is better as it is more intuitive to understand. @deepmap-marcinr what do you think ?

[nsemikov]

Binary nullable is a good option! But I'm sad what it's not implemented yet. Is there any updates since aug?

[jfcavalcante]

Is there any chance of merging the PR that is solving this issue?

[deepmap-marcinr]

Let's make this PR flaggable via the Configuration structure, then it's good to go. Whenever we've made breaking changes, people complain, so let's be nice about it.

I've been away for a while, sorry for tardy responses.

[vennekilde]

Would be awesome, as e.g. https://github.com/uptrace/bun struggles with pointer slices