Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid pointer redirection for Optional slices in Go #198

Merged
merged 9 commits into from
Sep 24, 2024

Conversation

hculea
Copy link
Member

@hculea hculea commented Sep 18, 2024

In Go, optional values are represented by pointers. This makes sense for most types. For example, using a "*bool" pointer allows for the type to express three values: nil, true or false.

In the 1Password SDKs, we expose the types generated by typeshare (e.g. see the types for Go) to be user facing.

Typeshare currently uses a pointer redirection to mark the Go types as optional. While most of the values are translated correctly, using a pointer to a slice (i.e. the translation of Vec<T> currently is []*string) is not usual in Go, and it leads to more complex code for the users of the SDK.

This is because, in Go, slices are already reference types. That is, passing a slice around passes a reference to the underlying data.

However, an edge case can occur:

type A struct {
    Slice []string `json:",omitempty"`
}

type B struct {
    Slice *[]string `json:",omitempty"`
}

For type A, both Slice: nil and Slice: []string{} have the same JSON serialisation (Slice is omitted).

For type B Slice: nil and Slice: []string{} both have a different JSON serialisation. In the first case, Slice is omitted. In the second case the field has the value [].

This, however, is rarely applicable in practice, and having this feature does not justify exposing an unintuitive user interface. Therefore, this PR is adding a configuration option disabling that for Go.

Copy link
Collaborator

@seanaye seanaye left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a unit test to assert this setting works as expected in both cases

@seanaye seanaye merged commit 5f1e202 into 1Password:main Sep 24, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants