On Tuesday, 18 February 2014 at 06:50:36 UTC, logicchains wrote:
Maybe it'd help things if they just directed any inquiries
regarding generics to the most popular preprocessor package?
There are a few around the community. I even wrote a tiny one
myself this morning; it can only handle simple functions like:
func myFun<T, S>(a, b ~T, u, v ~S) (~T, ~S, ~S){
return a + b, u*u, v*v
}
I can't claim code generation to be a terrible option, after all
D is code generation. I certainly have created, and used many
myself, and then there is also Regex and Pegged demonstrating
such power. But it is not without its problems, one of which is
right there in your comment.
* Debugging becomes more difficult, line numbers don't match.
* It is easy to hide details about what code actually exists.
But a preprocessor has extra negatives
* People will develop their own solution to a problem.
* Adds a dependency to the project
* Each project will use different preprocessors to address the
same problem or different problems (compatibility between
preprocessors?.
* Such projects won't be considered while the language evolves
** Either the generator syntax will be poor (hiding in comments,
which aren't actually sacred in Go)
** Or the generator risks breaking from language changes
However I don't think most of those who desire generics
appreciate the benefits of code generation and it would not be
reasonable to point them to such a solution (cpp has left a bad
taste in most peoples mouth)
This project was an interesting take on solving the perceived
problem. http://clipperhouse.github.io/gen/ (it even had to fix
the problems with the sort package)
