Eric you ostensibly forgot about the type of a callback function whose body varies at runtime and thus is statically unknowable. This is why the type of the function has to be typed for the contracts it requires.
On Wednesday, October 17, 2018 at 4:37:01 AM UTC+8, Eric Raymond wrote: > > > > 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.
