If you require that a single like type applies to all the labels in the parameter declaration, such that func f(a, b T like int, c, d T2 like string) means a and be must be like T's instantiating type, and c and d must be like T2's unstantiating type, then you get that.
If you only require a single like for any type T, something like func f(in T like int) (out T), then you get the type safety on return. Of course, this takes you back essentially to contracts, but with an alternative declaration for the type characteristics. Maybe it would be possible to use like in contracts in place of the example-base approach. On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote: > I think there are serious issues with your syntax for functions and > “templates.” For example, there doesn’t seem to be a way to specify > that two parameters to a function need to be the same type, or that > the return type will be the same as the parameter. The syntax from > the official proposal is superior in that regard. > > But replacing contracts with “like” definitely sounds like something > worth investigating. > > Andy > -- 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.
