On Tuesday, October 16, 2018 at 4:03:16 PM UTC-4, Ian Lance Taylor wrote: > > It's a feasible approach. But unless I misunderstand, testing > arguments at the call site means that you've discarded contracts. >
I don't understand that claim. A contract (in my plan, an "implements" clause) is how you decide whether binding a template formal to a concrete type at the callsite makes sense . For example, if the generic function has the signature "func foo( a T, b T)" and contains the expression " a < b" and you bind the unspecified type T to a a concrete one based on the arguments passed to foo at callsite, you either compile "a < b" using the "implements <" method of the concrete type or throw an error. > 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. That doesn't seem to me to entail more risk than *any* change to the generic function would. > 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. > Can you exhibit any scenario in which, under my plan, any validity check has to wait until runtime? If it helps, think of an "implements <" method as a text-rewrite rule that is evaluated before code generation. Anywhere you see "a < b" and the operand type has an "implements <" method, the expression is effectively replaced by a method call. -- 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.
