#define defmax(name, type) type name(type a, type b) { return a > b ? a : b; }
This seems to be exactly how you would define a "generic" max function in Go with the current tooling, too. Which is a shame because C macros just aren't good enough. #define defmax(name, type) type name(type a, type b) { return a > b ? a : b; }
This seems to be exactly how you would define a "generic" max function in Go with the current tooling, too. Which is a shame because C macros just aren't good enough.> 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);
a lot of people (not everyone) would be very happy, even though there is no theoretical difference at all. I've seen countless proposals for Go generics that do nothing more than that, but have been rejected for obvious reasons. That's where I'm coming from. template<type> max(...) into #define defmax(type) ...
and max<int>(...) into defmax(int); max(...)
The resultant code will be identical once it has gone through the preprocessor. All you are gaining is prettier looking code, which shouldn't be discounted, but generics are about more than that. Yet this example would be quite satisfactory to many regardless; curiously even you seemed excited about it.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.