[theseoafs]

   #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.

[staticint]

Good example. Thanks.

> 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.

[pcwalton]

There's a huge theoretical difference. To name one obvious example, the template is hygienic with respect to name collisions, while the macro isn't.

[staticint]

I think you may be reading too much into the hypothetical implementation. It was highlighted as nothing more than syntax sugar, after all. If all you do is translate:

    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.

[pcwalton]

> The resultant code will be identical once it has gone through the preprocessor.

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.

[staticint]

> Well, sure. Hand-written assembly is also identical to compiled code

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.