On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond <e...@thyrsus.com> wrote: > > 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 ==. .
It's a feasible approach. But unless I misunderstand, testing arguments at the call site means that you've discarded contracts. This means that a change in the generic function, which happens to introduce a new use of the parameter, can cause a failure at the call site, which may be far away. It's possible that that is the best way forward. But it's problematic, for the reasons discussed at the "type contracts" section of the design draft. This is less of a problem in a dynamic language like LISP than it is in a nominally compile-time-type-safe language like Go. Ian -- 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.
