I think the idea we should focus on here is "The type is the contract". Instead of specifying a contract though operations, just use concrete types, including primitive types to specify the desired qualities of the generic type.
Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak: > > 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.
