Description
The nominal original policy for this repository was to use pointers for Go properties that were not always REQUIRED. This was codified in #287, and then reversed in #656 to be anti-pointer. However, in #764, maintainers are again asking for pointers. I think we should have a consistent position on this issue, so here's an attempt to summarize the arguments on each side:
Anti-pointer
-
Pointers make the Go code more complicated (see @vbatts here and @vishh here). And as evidence that this is a thing, see @cyphar's recent bugfix in validate: fix spec.Hooks nil dereference runtime-tools#361.
-
Distinguishing
null/ unset from the zero value is not useful when both have the same semantics (see @vishh here and here and @mrunalp here)In some specific cases:
- An explicitly empty-string
cgroupsPathcan mean “let the runtime handle it” which is what unset means (see @mrunap here).
- An explicitly empty-string
-
Distinguishing
null/ unset from the zero value is not useful when the zero value is invalid (see @crosbymichael here).In some specific cases:
- No need for pointers on
CpusorMems, since we can have a runtime no-op for all three cases (null/ unset / empty-string) (see @crosbymichael here)
- No need for pointers on
-
String pointers are never useful (see @crosbymichael here).
Pro-pointer
-
Pointers provide a consistent way for Go consumers to determine if the property was
null/ unset (see me here; @cyphar here; @crosbymichael “where the zero value means something for our settings” here, @hqhq here, @munralp here, @duglin here).In some specific cases:
-
@mrunalp here, @hqhq here, and @vishh here and here, and me here on making
DisableOOMKillera pointer to distinguish “set true”, “set false”, and “leave alone”. -
@cyphar here on a pointer for
Cpusso we can fail on an invalid empty-string, backed up by @mrunalp here -
@crosbymichael here on a pointer for
Timeoutso we can fail on an invalid zero.
-
-
proposal: encoding/json, encoding/xml: support zero values of structs with omitempty golang/go#11939 means that
omitemptyrequires pointer properties for structs. More on this in Make the Platform field actually optional. image-spec#625.
Consistent policy
While “pointers for every omitempty property is nice and consistent, the consensus position seems to be that the increased complication of pointer handling outweighs the desire for consistency there. That's fine.
We only explicitly support null for some properties inside linux.resources.devices (which I should have removed #656). I haven't heard anyone calling for the ability to distinguish between null and unset in Go, but that's probably orthogonal to the pointer policy because you'd have to use interface{} to do it.
We have to use pointers for optional structs, because of golang/go#11939.
So the contentious point seems to be:
For optional properties where the zero value is invalid (e.g.
cpusand, if #764 lands,timeout), do we want to be able to distinguish the cases in Go? Or can Go consumers assume that validation has already been done and treat Go's zero-value cases as “unset”?
We have had maintainers on both sides of that line, and while having an evolving policy is fine, I'd rather not have an inconsistent policy. I'm happy to submit pull requests to unify the repository around whichever position we want to adopt.