This should work on your example:
var zeroValue V
On Mon, May 30, 2022, 6:39 PM Will Faught <w...@willfaught.com> wrote:
> Hello, fellow Gophers!
>
> Currently, if I understand correctly, there's no expression for the zero
> value for a type variable:
>
> type Map[K comparable, V any] struct {
> ks []K
> vs []V
> }
>
> func (m Map[K, V]) Get(k K) V {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return zeroValue // cannot currently express this
> }
>
> This is a trivial example, but I've seen real questions about what to do
> in these situations.
>
> Currently, if I understand correctly, the only way to do this is to
> declare a variable, and return that:
>
> var zeroValue V
> return zeroValue
>
> Why not allow nil to be used as the zero value for type variables, to fill
> this gap?
>
> return nil // == V(nil)
>
> At runtime, nil would be the zero value for the specific type argument.
>
> Nil could actually be interpreted as the zero value for every type, even
> outside of generics. The word "nil" means
> <https://en.wiktionary.org/wiki/nil#Noun> zero, anyway. This would be
> handy in situations where you make a type a pointer just to avoid lots of
> typing. For example:
>
> if condition1 {
> return ReallyLongStructName{}, fmt.Errorf(...)
> }
> if condition2 {
> return ReallyLongStructName{}, fmt.Errorf(...)
> }
>
> Instead, you could keep the non-pointer type, and then do:
>
> if condition1 {
> return nil, fmt.Errorf(...)
> }
> if condition2 {
> return nil, fmt.Errorf(...)
> }
>
> It would also solidify the type abstraction concept of generic functions,
> where functions varying only in concrete types can be abstracted into one
> generic function with type variables. For example:
>
> // Same implementations, different types
>
> func (m MapIntInt) Get(k int) int {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil, not 0, but means the same thing for int
> }
>
> func (m MapStringString) Get(k string) string {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil, not "", but means the same thing for string
> }
>
> // Same implementation, abstracted types
>
> func (m Map[K, V]) Get(k K) V {
> for i, k2 := range m.ks {
> if k2 == k {
> return m.vs[i]
> }
> }
> return nil // nil is 0 for int and "" for string
> }
>
> Similar to how generics required an inversion of the meaning of interfaces
> to be type sets, perhaps generics also requires an inversion of the meaning
> of zero and nil values, where every type has a nil (default) value, and for
> number-like types, that just so happens to be the number zero, but for
> other types, it could be whatever makes sense for them.
>
> Anyway, I thought it was an interesting idea. Thanks for reading!
>
> --
> 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/CAKbcuKjePVMPH1Fxv3tWAAm_msjAZKmtbJs2EMkQ7WGEgtAqyA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAKbcuKjePVMPH1Fxv3tWAAm_msjAZKmtbJs2EMkQ7WGEgtAqyA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEd86TzRiQesDG%3Da-8Cjr084AdPGi0eTGV6yK%2BD4yr7gj17Kmw%40mail.gmail.com.
