On Fri, 1 Jan 2021, 17:49 da...@suarezhouse.net, <da...@suarezhouse.net> wrote:
> First of all -- awesome, thanks!!! > > Question 1: the need for the additional typeOf function you added at the > end, would that be needed in a future implementation or would that be > deduced in the existing reflect.TypeOf in the future? > It's not needed even now - I just included it because I think it's neat, and works correctly even when the type parameters are interface types. > > Question 2: this experience has shown me a bit better that anything is > possible but will take some getting used to. Do you think having an > "import generics" similar to unsafe as a separate in the actual "library" > part of the code would resolve the concerns on user cleanliness? This > example I think shows me that if the library writer is careful the end user > of the library would have a very minimal impact. As a side note, I started > playing with this to understand the other generics long thread going on :-) > Personally, my main concerns about cleanliness are not about when packages are trying to minimise the generic API, but that people with experience in other languages bring a lot of the patterns they've previously used until Go. Pervasive use of iterators is one such - I can easily see a future where people are criticising the Go compiler because it can't optimise some iterator-based solution enough. Another concern is that people will use type parameters instead of interfaces for their efficiency properties rather than for correctness (for example by using a type parameter as an argument to a constructor rather than using an interface value, making the type harder to use because of the need to reference the type parameter every time the generic type is used). Many people seem to be aiming that the Go compiler will monomorphise all generic instances. I'm not sure that that's a good idea because it is likely to increase the pressure to use generic types even when there are sufficient usability disadvantages. Instead, I am hoping that the cost of invoking a method on a generic value will be roughly comparable with that of invoking a method on an interface value, thus hopefully making it easier for people to choose to use the simpler non-generic solution without incurring too much relative performance overhead. > Thanks again for solving this so quickly!!! > David > On Friday, January 1, 2021 at 10:50:57 AM UTC-6 rog wrote: > >> You need to declare the type parameters in the method definitions too. >> Something like this works OK: >> >> https://go2goplay.golang.org/p/ZUAVncRrmZW >> >> cheers, >> rog. >> >> On Fri, 1 Jan 2021 at 15:06, da...@suarezhouse.net <da...@suarezhouse.net> >> wrote: >> >>> I thought I read the generics doc well but.. :-) Help is appreciated: >>> >>> I instantiate a generic table example here in line 41: >>> https://go2goplay.golang.org/p/SadxA0khqx7 >>> >>> Then I use it in lines 42 and 43. >>> >>> The errors I get are below: >>> prog.go2:67:10: cannot use generic type Table[colA, colB, colC >>> fmt.Stringer] without instantiation >>> prog.go2:72:10: cannot use generic type Table[colA, colB, colC >>> fmt.Stringer] without instantiation >>> >>> I am using the same table. The method belongs to the struct so I would >>> think should be considered instantiated and that I wouldn't have to repeat >>> in lines 42 and 43 the types. >>> >>> Is this a bug and it should infer since created in line 41 or what did I >>> misunderstand in the doc? >>> >>> Thanks in advance for the help! >>> David >>> >>> -- >>> 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/9c999eee-3887-4d64-a41d-9402a1103a47n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/9c999eee-3887-4d64-a41d-9402a1103a47n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/c0c30a34-af6f-4f32-8965-c84853d58377n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/c0c30a34-af6f-4f32-8965-c84853d58377n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJhgachPJ0Xt6E%2B54iatZaGVg2FWWk0i4E1%3DfomK%2B%2BaDCLitqw%40mail.gmail.com.
