>
> As to _why_ this is the case, the generics proposal has a section about
> that:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#permitting-constraints-as-ordinary-interface-types
@Jason Phillips Thanks for pointing me here.
@Ian Lance Taylor I agree with you that both "old"-interfaces and
type-interfaces have the same semantics. However, syntactically they are
different and this is the reason for my discomfort.
It makes total sense that my code sample won't work even if type-interfaces
could be used for variables in the future as the type could not be
determined at compile time. But this is very different from the way
"old"-interfaces work. In a slice of io.Reader's I can instantiate various
types that implement the interface and pass them on to some func consuming
an io.Reader.
Maybe this is only me not seeing the bigger picture and possible benefits
of reusing interfaces for type constraints. I am curious if there are other
cases than my described scenario where this might make total sense. For now
I remain skeptical though and find it very confusing trying to fit two
syntactically different things in the same term "interface".
Am Mi., 15. Dez. 2021 um 22:19 Uhr schrieb Ian Lance Taylor <i...@golang.org
>:
> On Wed, Dec 15, 2021 at 3:24 AM Leonard Mittmann
> <leonard.mittm...@gmail.com> wrote:
> >
> > I just learned that type constraints, which are defined as interfaces
> are actually not usable in all the places "normal" interfaces can be used
> in. E.g., why can a constraint interface not be uses as a struct type?
> >
> > Let's say I have the func `func Smallest[T constraints.Ordered](s []T)
> T`. How do I write a table test for this func? Intuitively one would try to
> store tests like this:
> >
> > tests := []struct {
> > Arr: []constraints.Ordered
> > Want: constraints.Ordered
> > }{...}
> >
> > But this is not permitted. Am I missing something why this behavior is
> should be considered good? If a type constraint is nothing like an
> interface... okay, but why call it interface then?
>
> Aside from the rest of the conversation, note that your suggestion is
> never going to work, because you aren't going to be able to write the
> next steps in which you try to instantiate a function with an element
> of a slice. You can only instantiate functions with types known at
> compile time, not with types known at run time.
>
> 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/CAGdsN_rtPyWwmBZOESfF-9DSR0c2J5vzgP0wy445UT5Yk4E_Ow%40mail.gmail.com.
