As a general suggestion:
Do not use fabricated examples, use concrete real-world examples.
Fabricated examples make harder to examine the practical side of generics
-- i.e. how would you solve a particular problem with/without generics. The
fabricated examples can suggest a problem where there is none,
alternatively they can trivialize the actual problem without solving it in
the first place. *And by concrete real-world examples, I really mean code
that someone would pay you to write.*
Talking about reusability of faciliated code is nonsense, because that code
isn't usable in the first place.
On Wednesday, 22 June 2016 10:49:06 UTC+3, andrew...@gmail.com wrote:
>
> Sorry for typo and possible spam but correct example here:
>
> type Foo<K, V> interface {
> Get(key K) V
> Set(key K, val V)
> }
> func foo() (int, Foo<string, int>) {
>
> // Typo: foo := &Foo<string, int>{}
> foo := &fooStruct<string, int>{}
> // ...
> foos := []Foo<K,V>{}
> // ...
> k := "London"
> // ...
> return 55, foo2(foos, 55, k)
> }
> // This code is type safe and reusable
> foo2<K, V> (foos []Foo<K,V>, i int, key K) (V, Foo<K,V>) {
> foo := foos[i]
> return foo.Get(key), foo
> }
>
>
>
>
--
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.
