Empty repeated fields are being converted to nil instead of a non-nil empty slice.

[Jonathan-Landeed]

Is your feature request related to a problem? Please describe.

Some golang libraries have slightly different behavior for empty slices and nil slices. I've run into an issue where I was passing a value from a repeated proto field to the WHERE clause of a sqlc query. Unfortunately, protoc-gen-connect-go considers the default/empty value for a repeated field to be nil. This is being interpreted by sqlc as NULL instead of an empty array, which broke my filter logic.

I'm not to familiar with the internals of the generated code, but this is a clear example of generated code using nil for an empty slice when something like a string doesn't get the same treatment.

func (x *Message) GetCustomerIds() []int64 {
	if x != nil {
		return x.CustomerIds
	}
	return nil
}

func (x *Message) GetCustomerName() string {
	if x != nil {
		return x.CustomerName
	}
	return ""
}

An optional string would be represented as a pointer and default to nil. Golang slices are already pointers, but luckily we don't need to distinguish between nil and non-nil slices because repeated fields cannot be optional protocolbuffers/protobuf#10489

Describe the solution you'd like

Would it be possible to default to non-nil empty slices instead? Something like return []int64{}. This wouldn't break anything for people correctly checking for nil/empty slices with len(slice) == 0, but might break code for anyone relying on slice == nil.

Describe alternatives you've considered

We can't distinguish between omitted/empty repeated fields by using both nil and an empty slice, as both are the same on the wire.

Currently I'm having to write an explicit nil check on my repeated fields to convert them to empty slices (or edit my postgres queries to handle NULL).

[emcfarlane]

Hi @Jonathan-Landeed this would be a change in protoc-gen-go not protoc-gen-connect-go as field methods are on the message types. See this related issue: golang/protobuf#1348

For SQLC mapping directly to protobuf types will be difficult. I'd recommend to keep the protobuf types at the API layer (at the edge where you require encoding to transmit the messages), and have a separate representation for your internal database structure. This would then require mapping of the protobuf type to the sqlc type, where you could check for nil slices and create an empty slice instead.

Closing as I don't think this is an issue with connect-go.