EDIT: Granted, it is an unusual formulation, and far less convenient.
Granted, there are some quite complex systems out there where generics could deliver truly valuable type safety. I doubt all the systems that are that complicated really need to be.
The likelihood that a programming language feature will be over/mis-used is directly proportional to how nifty it is.
Specifically, how?
EDIT: Surprisingly, programmers do a lot of this "just knowing." You'd think that a supposedly quantifiable field would have more, quantification. Going by "guts" is particularly bad in big enterprises, where decisions are often more about politics than about quantifiable results.
The former means more code. That can be hidden out of view, but it means more work when fixing bugs in that code, introduces subtle bugs when one forgets to apply a bug fix to a 'copy', and slows down compiles.
The latter means adding casts to your code that make it harder to read and (more code is buggier code) also runs the risk of introducing bugs.
The two-and-halfth option is to use some preprocessor to generate code variants for you. IMO, that is just a bad implementation of generics.
Yes, that is not quantified, but I think it covers the how* part.
The only real issue is that the things you shove into Objective-C containers must themselves be Objective-C types, which means using NSNumber and NSValue everywhere for raw C types. The new Objective-C @literal and @(expression) syntax, however, should make such code cleaner in the future...
Your post is a good post.
GTK+ on Windows doesn't really have a particularly good reputation among myself and some of the people I know, and I didn't know native GTK+ for Mac was a thing until very recently.