Keith, The genreal idea is that type parameters can only be specified in 2 places right now: on package-level type definitions and on package-level function definitions. I am waffling on the viability of allowing methods on already-parameterized types to specify type parameters as well, but that's a digression and will likely present a clear answer as I do more work and test more use cases.
You're correct that typechecking and type parameterization are tightly coupled logically, but conceptually it feels like 2 separate phases: type-checking type expressions, and type-checking concrete objects such as variable names, etc. If I can nail down the concrete type represented by a type expression, I can do type replacement without knowing the type of every named object, given that the type checking logic that exists will catch the more low-level type errors. The brunt of the work in the existing type checker would then become incorporation new meta data to allow error messages to refer to the user-specified syntax (example: say GenType.[int] rather than GenType_generated_for_int_xhagdhd). I will most definitely document gc with any information I glean during this process, although I think that is a separate project on its own, hah. -- 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.
