On Wed, Dec 15, 2021 at 8:29 AM Brian Hatfield <bmhatfi...@gmail.com> wrote: > > I read that and I genuinely do not understand why interfaces now mean two > distinct incompatible things. I think this is going to confuse a lot of > people.
This is perhaps pedantic, but the two meanings are not incompatible. The set of interface types that may be used as the types of a variable are a strict subset of the set of interface types that may be used as constraints. What is new in 1.18 (among other things) is that it is now possible to write an interface type that may not be used as the type of a variable. This is a loss of orthogonality but it doesn't mean that interface types mean two different things. It is possible that in the future we will permit variables to have interface types that use embedded non-interface types, approximation elements, and union elements. That would be a significant change to the language and we've chosen to separate that change from the complex addition of generic support. And we may never make that change. We don't know yet. Ian > On Wed, Dec 15, 2021 at 11:09 AM Jason Phillips <jasonryanphill...@gmail.com> > wrote: >> >> 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 >> >> On Wednesday, December 15, 2021 at 11:05:36 AM UTC-5 Jason Phillips wrote: >>> >>> @Leonard, type constraints can only be used as type parameters, using them >>> as normal interfaces is currently not allowed. See the notes in the draft >>> release notes[1] or the draft 1.18 spec[2]. >>> >>> > Such interfaces may only be used as type constraints. >>> >>> > Interfaces that contain non-interface types, terms of the form ~T, or >>> > unions may only be used as type constraints, or as elements of other >>> > interfaces used as constraints. They cannot be the types of values or >>> > variables, or components of other, non-interface types. >>> >>> @Kurtis, that issue is about embedded fields (fields without explicit field >>> names) that use type parameters. >>> >>> [1] - https://tip.golang.org/doc/go1.18 >>> [2] - https://tip.golang.org/ref/spec#Interface_types >>> >>> On Wednesday, December 15, 2021 at 10:47:20 AM UTC-5 kra...@skepticism.us >>> wrote: >>>> >>>> This was asked 15 hours ago in the thread with the subject line "Go 1.18 >>>> beta1: Embedding Type Parameter in struct definition is an error". :-) >>>> >>>> See https://golang.org/issue/49030. >>>> >>>> On Wed, Dec 15, 2021 at 3:24 AM Leonard Mittmann <leonard....@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? >>>>> >>>>> -- >>>>> 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...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/53df110e-8f34-490a-9b77-610dacffdbcfn%40googlegroups.com. >>>> >>>> >>>> >>>> -- >>>> Kurtis Rader >>>> Caretaker of the exceptional canines Junior and Hank >> >> -- >> 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/0ae9aed8-72d4-42a2-acf0-16d0bd6b08ecn%40googlegroups.com. > > -- > 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/CANGiwgY2%2B-xEBzezeh-D_0dv2hQXreWLsiXoOSP%2Bw-LUV%3DkVaw%40mail.gmail.com. -- 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/CAOyqgcU76KAJLyDTr5RFPAaMJrq%3DAPcVX7p9zuRNDo2-AuzZkQ%40mail.gmail.com.
