On Mon, 22 Jun 2020 at 15:57, Andrew Werner <awerne...@gmail.com> wrote:
> On Monday, June 22, 2020 at 10:17:01 AM UTC-4, rog wrote >> >> On Mon, 22 Jun 2020 at 14:59, Andrew Werner <awer...@gmail.com> wrote: >> >>> Oh! It’s saying that *B implements the constraint, nifty. Is this idea >>> in the current proposal? >>> >> >> Yes. See >> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-methods >> >> >>> I agree that it’ll do the trick in the same way as your second proposal >>> and my proposal and is even a bit cleaner. That being said, it still seems >>> worse than having a mechanism to indicate that a type really is an array >>> and can be syntactically used as such, no? >>> >> >> I'm not sure. ISTM that there is a reasonable workaround and that the >> alternative might significantly complicate the generics proposal. The >> authors aren't trying to address every possible generics use case, >> especially when it's possible to work around the problem, and I like that >> approach :) >> > > Cool, I'm on board with this view. I'll adopt this approach and see how it > feels. Hopefully with aggressive inlining the trip through the compiler > will be able to optimize the access as though the array were being indexes > directly. > I wouldn't necessarily expect aggressive inlining of generic calls. This isn't C++, and the direct corollary of aggressive inlining is code bloat from excessive specialisation. I'm expecting performance somewhat better than interface values because the calls can be direct, but not necessarily as fast as if everything was fully specialised. All this is still to be decided though, of course. > I think this is already addressed in the current design >>>>>>>> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#embedding-an-instantiated-interface-type>. >>>>>>>> You are allowed to directly embed type-parameters, and they have the >>>>>>>> name >>>>>>>> of the template argument (rather than its instantiated value). >>>>>>>> >>>>>>> Cool, I'll try it out. I found it not compiling with `go tool go2go` >>>>>>> in my first pass. Maybe I was holding it wrong. >>>>>>> >>>>>> > I'm just re-visiting this now and I wonder if it's what I want. While > indeed you can embed a type parameter, it's not clear that you can embed a > type that is parameterized on a type-parameter. For example the following > example is definitely kosher but the one after it is not as obviously > kosher. I don't think I was clear enough in my problem statement but I'm > requesting that the latter be allowed and that the embedded field in that > case be `List`. Am I still misunderstanding something? > > type Foo(type T) struct { > T // Ok > // ... > } > > type Foo(type T) struct { > list.List(T) // Seemingly not ok > // ... > } > > This issue is addressed here > <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#embedding-an-instantiated-interface-type>. > Because of a grammatical ambiguity, you have to do: > type Foo(type T) struct{ (list.List(T)) ... } cheers, rog. -- 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/CAJhgacjGRiVDwMmTLh_6Jw0EMR1%2B%2B3MQ-QAEDDFJAhA2bApgQg%40mail.gmail.com.
