Re: [go-nuts] Constraints for generics

Using a subset of types makes it unusable for generic collections. You don’t want to write multiple tree maps. That is what Go has today and what generics is primarily attempting to fix, so at the end of the day if I can’t write a completely generic collection class I will bet the farm that your

Re: [go-nuts] Constraints for generics

On Sun, 30 Sep 2018 10:18:25 -0500 robert engels wrote: > Yes, it is a very similar if not the same issue, > since the type switch must be at the TOP LEVEL No, in my CGG `for type switch` contract does not need to be at top level. It is proposed in Chris' but still yours: > you guarantee the e

Re: [go-nuts] Constraints for generics

On Sun, 30 Sep 2018 at 17:56, robert engels wrote: > > I think you address the first, with a “toUnsigned” method, but I am not sure > that semantically makes sense for a lot of types except numerics, but > “shifting” is only supported on numeric types anyway. > > I have always thought that not h

Re: [go-nuts] Constraints for generics

I think you address the first, with a “toUnsigned” method, but I am not sure that semantically makes sense for a lot of types except numerics, but “shifting” is only supported on numeric types anyway. I have always thought that not having automatic conversions for numerics in Go is a bit strang

Re: [go-nuts] Constraints for generics

On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote: > > The static switch is a big problem. For any complex method you are going > to completely duplicate all of the code. Not good. > > Far better to map operators to interfaces then you only need a single > method implementation.

Re: [go-nuts] Constraints for generics

Btw, I realize that in this particular case, you would probably write a “compareKeys” method to perform the key comparison, and that would have the type switch, but I was trying to show that in general a method that uses a lot of math and or comparison operations will need to be duplicated, prob

Re: [go-nuts] Constraints for generics

Yes, it is a very similar if not the same issue, since the type switch must be at the TOP LEVEL, you guarantee the entire method will be duplicated multiple times. How you continually do not see the problem with this I am not sure, but I think it is because you are using trivial methods to “test

Re: [go-nuts] Constraints for generics

> Robert Engels wrote about what >> Christian Surlykke wrote: > The static switch is a big problem. For any complex method you are going to > completely duplicate all of the code. Not good. Now the same straw man argument I read in "critique" about my [1] solution is raised against other per

Re: [go-nuts] Constraints for generics

The static switch is a big problem. For any complex method you are going to completely duplicate all of the code. Not good. Far better to map operators to interfaces then you only need a single method implementation. > On Sep 30, 2018, at 5:33 AM, Christian Surlykke wrote: > > Hi > > I ma

[go-nuts] Constraints for generics

Hi I made a proposal for generics with constraints about ½ a year ago, which I posted to the (very long) thread on issue 15292. I've now made a version 2 , in case anybody would like to read it. This version adapts to the ge