[Fwd: Re: [go-nuts] Re: Generics false dichotomy]

[Jesse Phillips]

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)