I'm sorry it went badly then.
Your example intrigues me, isn't an interface enough?
Is what bother you that the return value won't be typed T but IIncrementable in go?
Your example intrigues me, isn't an interface enough?
Is what bother you that the return value won't be typed T but IIncrementable in go?
My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts.
So, the library now gets these functions, and does all the filtering on other threads.
So either I have to replicate the entire async code for every type, or I can’t keep type safety.
That’s the same mistake C did with void, Java did with Object and corrected with generics in 1.5, just called interface{} this time.
And while with python and Java, even if I circumvent the type system, I can still use annotations (see typed python, or JetBrains @Contract, Google’s @IntRange, etc), with Go I have nothing of that sort.
Types are useful to provide safety, if your type system has to be turnt off, then I am losing all that safety, and might as well code in PHP (although they also* saw that mistake, and are fixing it now, with 7.0 and later).