The provided tooling provides templating, which isn't dissimilar to where many other languages stop in their generics journey. The interface does leave a lot to be desired, granted.
func max(a, b T) T {
if a > b {
return a
}
return b
}
$ gofmt -r 'T -> int' -w max.goWhat distinguishes templates from macros is that templates deeply interact with and are instiantiated at the time of typechecking. Macros, on the other hand, are expanded at parse time (or, in more sophisticated implementations, at name resolution time).
# Common pattern in other languages
max<int>(1, 2)
# Similar pattern in Go
#go:generate gofmt -r 'T -> int' -w max.go
max(1, 2)
Although you do have me curious how you'd implement max in C in this type-safe way using standard tooling:
#define max(a, b) (a > b ? a : b)
#define defmax(name, type) type name(type a, type b) { return a > b ? a : b; }
> Which is a shame because C macros just aren't good enough.
No disagreement here. However, that still perfectly satisfies what may people claim they want in generics, especially those who most frequently trumpet that Go is lacking them. If we took that exact macro and added a little hypothetical syntactical sugar:
template<type> type max(type a, type b) {
return a > b ? a : b;
}
max<int>(1, 2);
template<type> max(...) into #define defmax(type) ...
max<int>(...) into defmax(int); max(...)
Well, sure. Hand-written assembly is also identical to compiled code, but we still have compilers :)
> All you are gaining is prettier looking code, which shouldn't be discounted, but generics are about more than that.
Yes.
> Yet this example would be quite satisfactory to many regardless; curiously even you seemed excited about it.
I don't think macros are a satisfactory replacement for generics, no. I don't know how I seemed "excited" about it.
I mean when you convert the template<type> statement to the #define statement with the hypothetical preprocessor, it would be the same as if you had written the same code using #defines originally. They are functionally interchangable. If this satisfies generics in your mind (I don't think this describes you, for what it is worth), then standard C macros are more than sufficient to cover all the cases you would want, albeit less pleasant to type.
> I don't think macros are a satisfactory replacement for generics, no. I don't know how I seemed "excited" about it.
Consider your previous post misinterpreted then. It read to me like you thought the hypothetical code was theoretically different and solved problems with the previously provided macro, even though it was the exact same macro in both cases. The only difference was the slightly different syntax. Which, I might add, anyone can fairly easily add something similar to their Go code if they really wanted to.
No, it doesn't. Not even close.
Even something like generic List<T> and sort<T>(List<T>) (separately compiled) will fall down because that simplistic scheme doesn't give each generic type and function a different name, and there's no way for sort<T> to look up whatever name List<T> got instantiated into.
There are also all sorts of hairy issues you will get into when you have name resolution and separate compilation: how do you make sure the macro got instantiated into the same lexical environment that it got declared in? This matters a lot when you have package A exporting a bunch of generic types and functions for package B to use, and it's going to be B doing the expansion using B's types. Even if you set up things just right to resolve the names in the proper lexical scope, how can B's expansion of A's templates use private symbols from A?
Finally, you have the dreaded C++ template error message problems, except they're going to be even worse with this scheme because the compiler is going to complain about code post-textual-replacement, with no way to interpret the chain of events that led to the error. At least clang and GCC have lots of semantic information that they can use, since templates are expanded during semantic analysis.