On Tuesday, October 16, 2018 at 9:44:23 AM UTC-4, Ian Lance Taylor wrote: > > It's not clear to me what other aspects of various generic proposals > you are picking up here.
The answer is "none of them". That wasn't my goal, because all the previous generics proposals I have seen struck me as overcomplicated and un-Go-like. What I was attempting to demonstrate was something minimal and clean that would handle your smoke test and the common cases that people who say they want generics seem to want to cover, such as your smoke test - min and max - and reordering a slice of elements of a type with a sortable contract. How are you imagining that we would write > the function that merges two channels? Exactly as you did, except I would omit the type parameter. It's unnecessary weight. New rule: A function on variables of undefined formal-argument types compiles to a template (not a textual template - we don't want identifier capture). At each callsite of the function, the undefined types in the formals are bound to the types of the arguments in the call. If every operation in the resulting code is defined, the code compiles as if the generic function had been written with the actual argument types at the callsite. If not, the compiler throws an error on each undefined operation. (Of course, operation definitions forward through "implements" clauses.) What could be simpler than that? No additional syntax, and it's easy to model in your head There's precedent for it working; I'm an old LISPer and in that world what I just said can be summarized as "a function with a formal of unspecified type acts like a hygienic macro". Before we tackle the graph example, let's examine this new compilation rule for traps. Call me crazy, but I think we just got parametric polymorphism with zero additional complexity load on the rest of the language. Yes, compiling those templates in such a way that they can be instantiated at callsites from the compiled version will be interesting, but there's an obvious trick where you substitute pass-by-pointer-reference-to-the-stack for pass-by-value in order to make every reference to an argument have constant width regardless of what its concrete type is. You're probably already doing something similar for interfaces. As the meme goes, "Prove me wrong". If nobody does, we now have both parametric polymorphism and a complementary contract system at the cost of one (1) new keyword and (1) interaction with the rest of the design - overloading pointer types has to be forbidden in order not to break ==. . -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
