Skip to content

Instantly share code, notes, and snippets.

@PeterRK
Last active October 16, 2018 03:59
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save PeterRK/41d4d3f54b8db55cd616403fd5a389f3 to your computer and use it in GitHub Desktop.
Save PeterRK/41d4d3f54b8db55cd616403fd5a389f3 to your computer and use it in GitHub Desktop.
package level generics

Package level generics may look less confusing.

package abc(Key,Value)

contract CompileCheck(a1 Key, a2 Value) {
	//...
}

type Pair struct {
	K Key
	V Value
}

func NewPair(k Key, v Value) Pair {
	return Pair{K: k, V: v}
}
package xyz

import "abc(int32,float32)" myabc

func newPair() myabc.Pair {
	return myabc.NewPair(1, 1.0)
}

Introduce two step compilation. Firstly create abc[Key,Value].lib from source. Then create abc(int32,float32).a from abc[Key,Value].lib . Both abc[Key,Value].lib and abc(int32,float32).a can be saved to reduce next compilation time.

@champioj
Copy link

champioj commented Aug 30, 2018

Hi, I've got some comment about your idea.

Why not directly

package abc type (Key, Value)

So it is self documenting and you don't need to declare the types twice.
It would work really well for the std/container libraries. The elephant in the room is the rest of standard libraries.
sync.Pool and sync.Map would have to be placed in a new package .

I wonder how filter/map/reduce would be written. You don't want to import the package N times.
Perhaps it could be written like that:

package xyz

import "fmp" // FilterMapReduce package

func test() []int {
    f := func(int i) bool { return i % 2 }
    v := []int{1,2,3,4,5}
    return fmp(int).Filter(v,f)
}

And if you can infer the types, you could skip the type specification and do return fmp.Filter(v,f) (But I except this is the hard part)

I'm glad there is some discussion about package level generics because it feel quite simpler:
For package author, put everything in the beginning of your file and the the rest of the code is the same as today. You don't need for each of your method to add the type parameter.
For package user, either the package is one file like container/list and it's really easy to understand just by ready the first line. Or for bigger package it could be placed in doc.go

P.S I would not put the types in the import path and place the name in the beginning. Like that : import myabc "abc"(int32,float32)

@kirillx
Copy link

kirillx commented Sep 14, 2018

Support the idea of package-level generics.
It keeps the code clean and simple, unlike to C++ generics where you have to type in plenty of places making code a mess.
It also allows to keep call traces readable, by adding types to file names, rather then functions (which are long lines already).

@PeterRK
Copy link
Author

PeterRK commented Oct 16, 2018

Hi, I've got some comment about your idea.

Why not directly

package abc type (Key, Value)

I tried to make it impossible that define both abc(K,V) and abc(X,Y).
You are right. It's a better to let the compiler show an error in such cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment