style: Document recent Go-pointer exceptions

[wking]

The general rule seems to be:

If Go's default value has the same semantics we'd use for an unset
value, don't bother with a pointer.

I'm not sure how well that squares with the pointer motivation,
which sounded like:

We want a consistent way to identify unset settings.

But if the falsy values count as “unset”, maybe the “null is a
consistent identifier for unset” approach was never really viable.

I'm also not sure if the new style extends to integers where zero has
the same semantics as unset values. It sounds like Michael was ok
with no pointers for those values, but OOMScoreAdj (where zero
clearly means “do nothing”) got a pointer in #233. More clarity
on the threshold would be nice.

[vishh]

I disagree with bool values. How can I express "don't change a value of a flag" if the flag was boolean? "false" does not always mean "don't change".
I think it still makes sense to have pointers to booleans.

[wking]

On Tue, Jan 26, 2016 at 10:45:05AM -0800, Vish Kannan wrote:

+The exceptions are slices, maps, and booleans where the default
should be false, in which case omitempty is sufficient and no
pointer is needed ([source][no-pointer-for-slices] and
[source][no-pointer-for-boolean]).

I disagree with bool values. How can I express "don't change a
value of a flag" if the flag was boolean? "false" does not always
mean "don't change".

But sometimes false does mean “don't change” (and those are the
booleans where the default should be false). For example, the source
I link is you asking for a *bool → bool change 1 ;).

If my wording here comes across as “slices, maps, and booleans should
never use pointers” instead of the intended “slices, maps, and
booleans should not use pointers when Go's default for that type means
‘don't do anything’”, then I'm happy to push alternate wording.

[hqhq]

But sometimes false does mean “don't change” (and those are the
booleans where the default should be false)

That'll be a problem if we want some bool values to be updated (live update), we surely want to change some booleans from true to false.

[wking]

On Tue, Jan 26, 2016 at 06:03:44PM -0800, Qiang Huang wrote:

But sometimes false does mean “don't change” (and those are the
booleans where the default should be false)

That'll be a problem if we want some bool values to be updated
(live update), we surely want to change some booleans from true to
false.

Yeah, booleans where ‘false’ requires action should use pointers. I
guess the wording in 60b83df is based on my assumption that “default”
equals “don't do anything” 1. I've pushed 60b83df → d715acf with
wording to explicitly pick out “Go's default for the type is a no-op
in the spec” cases.

[mrunalp]

LGTM

[crosbymichael]

LGTM