Go Proposal: first-class support for sorting slices

sdegutis wrote: post #2

Since when did Go use Github for official proposals? Does it also use the Github repo for official development or is it still just a mirror?

The new proposal process is documented here, and goes through opening a GitHub issue: https://github.com/golang/proposal

Go "partly" uses GitHub. The git repo is a mirror, and code review / pull requests is done through Gerrit, but the issue repo is the official one.

Re: Go Proposal: first-class support for sorting slices

#5

Post by patates » Tue, Aug 16, 2016, 3:53 PM UTC

So the current approach is providing some popular functions which would normally require generics to implement as built-ins?

Re: Go Proposal: first-class support for sorting slices

#6

Post by icholy » Tue, Aug 16, 2016, 3:54 PM UTC

That interface{} parameter makes me cringe, but it makes sense.

Re: Go Proposal: first-class support for sorting slices

#7

Post by giovannibajo1 » Tue, Aug 16, 2016, 3:57 PM UTC

patates wrote: post #5

So the current approach is providing some popular functions which would normally require generics to implement as built-ins?

I think they should at least implement a few builtin functions (that can be "real" generics) for common stuff that manipulate slices and/or maps.

I'm thinking things like min/max, which are really distracting and are concepts that are more easily expressed as a concise function rather than an explicit loop.

Re: Go Proposal: first-class support for sorting slices

#8

Post by mattnewton » Tue, Aug 16, 2016, 4:00 PM UTC

patates wrote: post #5

So the current approach is providing some popular functions which would normally require generics to implement as built-ins?

I understand the want to avoid over architected designs, but relying on a single party (who is not associated with your product or business need) to bless every abstraction you can use in your code base seems like a recipe for pain and awkwardness. Definitely limits me from wanting to make significant investments in go.

Re: Go Proposal: first-class support for sorting slices

#9

Post by spriggan3 » Tue, Aug 16, 2016, 4:07 PM UTC

icholy wrote: post #6

That interface{} parameter makes me cringe, but it makes sense.

Go needs functions that support parametric types for collections. I'm not even talking about generics here as user defined types. Let's forget about generics or "the ability for developers to implement their own type safe containers".

Let's talk about the fact that functions in Go could support type parameters in signatures , something like :

   func Map(slice []V,func(element V)W)[]W {
      // ...
   }

What we have here is a guarantee that at compile time, this code is safe. We didn't introduce generics, slice is a Go slice of V and the result is a go slice of W.

The code should then be used this way :

    result := Map([]string{"a","b"},
        func(e string)string{ return e+"foo" } )

This is completely type safe, no reflection is used, the compiler knows all the types at compile time and no generic type was introduced. This is a good trade off and merely syntactic sugar that would enable developers to get rid of interface {} parameter + type assertions.

Re: Go Proposal: first-class support for sorting slices

#10

Post by catnaroek » Tue, Aug 16, 2016, 4:08 PM UTC

spriggan3 wrote: post #9

icholy wrote: post #6

That interface{} parameter makes me cringe, but it makes sense.

Go needs functions that support parametric types for collections. I'm not even talking about generics here as user defined types. Let's forget about generics or "the ability for developers to implement their own type safe containers". Let's talk about the fact that functions in Go could support type parameters in signatures , something like : func Map (slice []V,func(element V)W)[]W { // ... } What we have here is a…

This is nice, but generic functions are still generics.