On Tuesday, 18 February 2014 at 06:50:36 UTC, logicchains wrote:
On Tuesday, 18 February 2014 at 05:11:00 UTC, Jesse Phillips
wrote:
Of course, implementing generics isn't going to be enough for
me. It is just an indicator. You are correct that they will
want to get the implementation correct and avoid ruining "Go"
as we know it; that just means they'll avoid all the other
positive things I enjoy about D's templates and
meta-programming features.
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
}
Nothing like D's capabilities, but it's enough for most of my
needs. What's the problem with just using an unofficial
preprocessor for generics? If one package became popular enough
amongst the community, that might be enough to convince the
devs to adopt it when Go 2.0 comes around.
It is like traveling back in time when parametric polymorphism
was debated in university papers and everyone was inventing their
own code generation tool.
Back to mid-90's compiler technology when only Ada supported
generics, C++ started to adopt some form of genericity at ISO
meetings and everything else where academic languages like
Eiffel, Modula-3 or Standadard ML.
We are in 2014, not in the early 90's. So to ignore what happened
in mainstream language design in the last 20 years, is nothing
more than an opinionated political decision against generics.
--
Paulo