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.
--
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/71ef34df-1874-4f58-9177-5068015c4683o%40googlegroups.com.
