On Wed, Jun 24, 2020 at 3:47 PM i3dmaster <i3dmas...@gmail.com> wrote:
>
> On Wednesday, June 24, 2020 at 3:02:43 PM UTC-7, Ian Lance Taylor wrote:
>>
>> The current generics design draft doesn't support the kind of
>> constraints you are looking for.
>
>
> Is there or will there be a plan? Using generic types with [], map, etc can
> work on some use cases,
> but there are likely also use cases where custom container types would more
> appreciated to abtract
> or confine certain API surfaces. I wish Go authors wouldn't completely
> eliminate these possiblities.
Custom container types aren't going to support len or range.
Functions like len and range are built into the language, and only
work with language defined types. So if we want to abstract over
containers, we shouldn't start with len or range. We should start
with other mechanisms, and encourage container authors to implement
them, and figure out how to make them work with slices and maps.
>> I'm not even sure what you mean by "copyable". All Go types can be copied.
>
> Hm... I thought there are some aren't at least recommened to copy, e.g.
> Mutex, Cond, or any types that explicitly documented not to copy.
I see. That isn't a language restriction, though, it's just
documentation plus a convention for the vet tool. I'm not sure it
makes sense to define a constraint for it.
>> Note that you are using type lists in a way that doesn't look right.
>> To write a constraint that is a combination of other constraints, you
>> should use embedding, as in
>>
>> type Key interface {
>> comparable
>> fmt.Stringer
>> }
>
>
> Interesting, maybe I wasn't still quite not understanding the draft spec...
> What's the difference here?
>
> // Numeric is a constraint that matches any numeric type.
> // It would likely be in a constraints package in the standard library.
> type Numeric interface {
> type int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64,
> uintptr, float32, float64, complex64, complex128
> }
>
> Also, btw, it compiles just fine.
Using a type list, as in your Numeric example, means that the type
argument has to be one of the listed types. When you write
type Key interface {
type comparable, fmt.Stringer
}
it means that the type argument must be comparable or fmt.Stringer, or
some other type whose underlying type is comparable or fmt.Stringer.
But what you want is not a requirement that the type argument be
fmt.Stringer, but a requirement that the type argument implement
fmt.Stringer. And that is done by using an embedded interface.
Ian
--
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/CAOyqgcXnHBqC2fw5a_3QVwATmXzKbdcfubrgwijsLYPnxthM_g%40mail.gmail.com.
