> where it is important to permit only type arguments that can be compared
to nil
I see! As in, if we somehow got a "equalszero" constraint, then that
constraint would solve the problem I illustrate.
I believe that assertion is correct, but I also believe that is a stronger
assertion, and also that it introduces more of a new concept than a simple
"nil" constraint. (Unless you're looking for some way to make "any" work,
and introduce a zero keyword or something...)
Also, there's the ergonomics of having to make a zero value instance. Maybe
we can rely on the compiler to optimize it away, but at a minimum it adds
another required line of code in the implementation. E g:
func MaybeNuke[T nil](b bool, val T) T {
if b {
return nil
}
return val
}
func MaybeNuke(T zero](b bool, val T) T {
if b {
var nope T // an extra line!
return nope
}
return val
}
func MaybeNuke(T any](b bool, val T) T {
if b {
return zero[T]{} // maybe? seems weird
}
return val
}
This is because not all zero values can be instantiated inline with simply
T{}.
Sincerely,
Jon Watte
--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJgyHGNnRhoHr_C_Db-hZ1FiHqsMoNkbkLMfwVPdqSYijgq2ew%40mail.gmail.com.
