Thank you! My personal opinion from this small journey into this topic is what you all built here is very flexible and robust. Are you all at the point of "perfect is the enemy of the good"? What is the criteria that will define when this releases?
As I see it, if you use something like impact to...:
* newcomers - Can be zero if no core library changes in the first release
* existing users - same as above but does enable existing users to start leveraging where appropriate so may be a value add here
* future maintenance - ? not qualified to guess :-) but if this is all that is really outstanding at some point it can just be improved in place I would assume and hence the Voltaire question
Look forward to seeing this in a release soon and thanks again for all of the insight!
David
On 01/01/2021 6:38 PM roger peppe <rogpe...@gmail.com> 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!!!DavidOn 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:
cheers,rog.
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 instantiationprog.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.
--
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.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/D2RYwYj9KVM/unsubscribe.
To unsubscribe from this group and all its topics, 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.
Sincerely,
David Suarez
Gallup Strengths Finder: Achiever * Strategic * Relator * Ideation * Learner
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/1949179644.1134896.1609585491504%40email.ionos.com.
