On Wednesday, June 24, 2020 at 3:55:07 PM UTC-7 Ian Lance Taylor wrote:
> On Wed, Jun 24, 2020 at 3:47 PM i3dmaster <i3dm...@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.
>
So... ok. I guess type list constraints is going to only work with builtin
types then.
e.g. it would be useless (or maybe even wrong to write)
type ContainerLike interface {
map, [], mypackage.Container
}
because mypackage.Container is simply just not going to work (even if it's
implantation may just use the builtin map)
Will it work if mypackage.Container is an alias type of builtin map? e.g.
type Container(type K, V) map[K]V
>
> >> 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.
>
Sure, it might be fine if the language doesn't provide a builtin one, but
if it is possible for API authors to
define their own?
We could say
type Copyable interface {
type !sync.*, !mypackage.Container
}
of course, there is no support for negative constraints yet... But just
wanted to see we could possibly offer.
>
>
> >> 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.
>
Got it. I think I finally understand this part of the spec. They both are
syntactically correct, but have a very different semantic. Good to know.
>
> 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/4b85e456-c9fc-4eaf-8a90-e2bc9221c773n%40googlegroups.com.
