Discussed during today's maintainers call and internally. Overall, everyone agrees Option[T] is a good thing as compared to pointer-based optional fields. However, there's some pushback as this would make the API inconsistent (ie. vs what we already do for other fields), and introducing a new dependency which isn't widely picked by the community isn't great.

We might still do that change at a latter time, but for all optional fields at once. And the 2nd problem could be overcomed by the use of an interface to not force a specific implementation.

Since #47867 has been merged, let's close this one.

And the 2nd problem could be overcomed by the use of an interface to not force a specific implementation.

Interfaces are reference types, which have the same aliasing issues as plain pointers. I suggested adding a concrete facade type to the github.com/docker/docker/api package to allow us to swap out the underlying implementation without it being a breaking change. E.g.:

type Option[T] struct { v optional.Option[T] }

func (o Option[T]) IsSome() bool { return o.v.IsSome() }
func (o option[T]) IsNone() bool { return o.v.IsNone() }
// etc...