One of the problems with working with serialization of any kind is dealing
with unset vs the zero value. The usual way to get around this is to use a
pointer, nil is unset, non-nil is set. But this gets annoying when trying
to make literal values, because you can't take the address of a constant:
type Foo struct {
Count *int
}
f := Foo{ Count: &5 }
// cannot take the address of 5
I get that you can't take the address of a constant, because then you could
change it, even though it's constant... but the alternatives are really
clunky. Sure, you can make a helper function for it, but that just makes
your API significantly less user-friendly, either you need ugly, basically
useless functions in your API, or you force your consumers to make those
functions in every package that consumes yours. There's a ton of hacks you
can do to make it work without implementing functions, but they're each
more horrible than the last: https://play.golang.org/p/9r-JMFSx9C
I'd really like to see the composite literal syntax extended to work with
non-composite types, so you could do something like this:
f := Foo{ Count: &int{5} }
This would explicitly tell you that you're making a copy of the constant 5
and then taking the address of that copy, just like you would here:
type Bar struct {
Val int
}
b := &Bar{5}
It seems like it would be intuitive and backwards compatible.
Alternatively, I actually think it would be totally fine and intuitive to
just let you do &5, but I bet that has less likelihood of being accepted ;)
-Nate
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
