make() lets me specify a key and element type for a map collection but there's only one implementation of map. What about expanding on make() to where custom implementations of map can be specified instead? make() would accept a new argument that would let me indicate a factory mechanism to use to instantiate that map - but the types of the custom map would be those I specified in the call to make()
IOW, this is a proposal for leveraging an enhanced make() function as a way to get the advantage of compile-time enforced types - as generics provide in other languages - at least for collections. Maybe sets and list could be added as something that make() can instantiate as well. Of course, it's not exactly that simple as the custom implementation would need to be able to operate on the actual type in an appropriate way for that type. Which means things like keys would need to implement traits for comparison and hashing, etc. Or the dichotomy that Java has where generic type arguments can be references types but not primitive types - well, as long as the Go compiler always sees the full source code of the custom implemented collection, and things like a key type honored a trait that all keys should abide by, then that disctinction would need to be there in Go (perhaps). Am just blue saying thinking of augmentations that could be done to Go to get some of the benefit of generics without buying into full blown generics support. -- 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. For more options, visit https://groups.google.com/d/optout.
