It feels like, so far, all of the attempts to simplify the original design
wind up looking more complicated for little benefit (and reduced
functionality).
Re-using interfaces seems like it would mandate boxing, (or interfaces are
no longer interfaces as currently described, which would also be a major
change).
The original generic types and functions as described would permit unboxed,
direct access to fields, without relying on inlining, which can't be
achieved with the interface approach.
Whilst contracts do introduce some ambiguities, it's not obvious that these
are of genuine practical concern. E.g., yes calls on a field function type
look like method calls, but the contract just says you should be able to
call a thing, if you care that that is a method vs a value, you probably
aren't writing a very generic function.
Ian has pointed out before, this isn't really any different from types that
coincidentally support an interfaces method set, sort.Sort will not do
anything useful if you're types doesn't implement the correct semantic
contract required. It's not obvious that contracts should attempt to be any
more accurate.
On Tue, 11 Sep 2018 at 12:40 Jonathan Amsterdam <jbamster...@gmail.com>
wrote:
> * 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.
>
--
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.
