[Generics] Concise generics with package level types

[teelin...@gmail.com]

Imagine the following function definition, under the current proposal (I believe this is correct):

func (s MyMap(K, V)) DoSomething(k K, v V) (func(type K Hashable) (k K) (V, error)) {...}

At least for me, the above takes a while for me to grok. In my opinion the current proposed syntax gets confusing very quickly. I thought the featherweight go talk was awesome, and would love to see something as simple as using interfaces as constraints. Barring that change, I have a small proposal (idea?) to the existing draft:

It would make code much cleaner if we simply declared types at the package level, instead of on specific structs, interfaces, and functions. 

type StringableVector(type T Stringer) []T

Would become

package mypackage(type T Stringer)

type StringableVector []T

This has the benefit of being much easier to read. My guess is that most packages would get by with only needing 1 or 2 Generic types at most. Anything more than that should probably be split into multiple packages. To support packages that do require more types, we could treat the types syntax like struct instatiation. For example:

package mypackage(type T String, K Hashable, V interface{})

type MyMap {
  Key K
  Value V
}

The calling code could then be:

map := mypackage{K: int, V: string}.NewMyMap()

I acknowledge the latter might get tricky, and might need to heavily depend on the linker(?) to ensure that any code paths using the non-defined type are not called.

[haskell...@yahoo.de]

Why not put type parameters on packages?

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages

[roger peppe]

On Tue, 23 Jun 2020 at 17:33, <teelin...@gmail.com> wrote:

Imagine the following function definition, under the current proposal (I believe this is correct):

func (s MyMap(K, V)) DoSomething(k K, v V) (func(type K Hashable) (k K) (V, error)) {...}

I don't think that's quite right. You can't have function values with type parameters.

So I think your example could look more like this in practice:

    func (s MyMap(K, V)) DoSomething(k K, v V) func(K) (V, error) { ... }

 

That doesn't seem too unreasonable to me FWIW. It reads nicely from left to right, and everything except that first (K, V) declaration is just as things are today.

  cheers,

    rog.

[b97...@gmail.com]

My code shows that returning a generic function might be desirable.

The Filter function in my code is as follows:

        func Filter(
                type T interface{},
                Source Observable(T),
        )(pred func(T) bool) Operator(T, T, Source, FilterObservable(T, Source)) {
                return func(source Source) ((FilterObservable(T, Source))) {
                        return FilterObservable(T, Source){source, pred}
                }
        }

Despite the truth that Source is a type parameter of Filter function, the Filter function is actually returning a generic function. Source cannot be deduced by only looking at the input parameter of Filter function.

在 2020年6月24日星期三 UTC+8上午12:56:48，rog写道：

[roger peppe]

The draft proposal does not support generic function values. Doing so would make the compiler's code generation job much harder (or maybe not possible) because it would be considerably more difficult to enumerate all the possible instantiation parameters at compile time.

--
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/2863cb7a-4ba9-46b3-86e7-2043dfa1c9a7o%40googlegroups.com.