4 ms·
The "go generate" is a small step into the direction this will take, IMO It's not. The problem is the number of possible types you want to instantiate a generi
by danieldk 12y ago
The "go generate" is a small step into the direction this will take, IMO
It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite.
If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects.
'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
- PopsiclePete 12y agoLike I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
- Jweb_Guru 12y agoI mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.