I think the problem with the proposal is that it is going to be very hard for 
the compiler to know all of the operations a type can perform since for 
concrete types the methods can be spread across multiple files. With an 
interface it is only declared in a single location. 

> On Oct 18, 2018, at 2:20 AM, Beoran <beo...@gmail.com> wrote:
> 
> 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.

-- 
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.

Reply via email to