>
> * I think constraining type-parameters to channel/slice/map types might
> not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch
> T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type
> with element type Bar can be assigned to `chan Bar`, this would already
> allow most of the useful patterns. As-is there is a slight reduction in
> power over the contracts design, because `contract channelOfBar(v T) { ch
> <- Bar{} }` also allows element types that Bar is assignable to.
> `assignableFrom(Bar)` would enable pseudo-interfaces to do that too. But
> IMO it would be helpful to see cases where that's needed (AFAICT none of
> the ones mentioned in the design doc or problem overview do).
>
Some of the examples could be generalized. For instance, Copy(dest []T1,
src []T2) where T2 is assignable to T1.
How about merging channels c1 and c2 into c3? You could write this as
func Merge(type T)(c1, c2, c3 chan T)
but the more general version is
func Merge(type T1, T2, T3)(c1 chan T1, c2 chan T2, c3 chan T3)
where you can assign T1 and T2 to T3.
--
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.
