Try it with a user defined type. The only point of generic is to write a method once. So when I call it with another type it works correctly. So if you write the generic method with a like Foo but I want to call it with a Bar what methods does Bar need to implement ? All of the methods of Foo - hard to determine as a developer - easily anyway.
> On Oct 18, 2018, at 8:09 AM, Burak Serdar <bser...@ieee.org> wrote: > >> On Thu, Oct 18, 2018 at 6:35 AM Robert Engels <reng...@ix.netcom.com> wrote: >> >> I meant to say contract not interface. Also as a user of said generic >> routine how do I know all of the available method on a type I would need to >> implement as I don’t know which ones the method may be using... >> >> Interfaces solve the latter as I need to implement all of them in order to >> be an interface. >> >> On Oct 18, 2018, at 7:21 AM, Robert Engels <reng...@ix.netcom.com> wrote: >> >> 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. > > > I don't understand why that would be a problem. For a method > declaration of the form: > > func f(type T like (int64,float64)(a,b)) > > the compiler compiles f twice: once as func f(a,b int64) and once as > func f(a,b float64). In general, for a function f with multiple > parameterized types containing multiple "like" types, f is compiled > for all combinations of those "like" types. > > So the compiler doesn't need to know all the operations a type has. > >> >> 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. >> >> -- >> 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. -- 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.
