On Thu, Oct 18, 2018 at 8:01 AM Robert Engels <reng...@ix.netcom.com> wrote:
>
> 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.
I don't think the problem you described exists. Let's take this one
step further:
(I'll continue using the "like" keyword for now until something better
comes up. Also, Andy is right, the syntax has problems. I'll use a
syntax similar to the one given in the official proposal)
A type template is declared like this:
type T like (X,Y,...)
This means that any one of X, Y, ... can be substituted in place of
T. In effect, it is the intersection of the operations defined on X,
Y, ...
- If X is a primitive type such as int, any type derived from int
can be substituted.
- If X is an interface type, any type implementing X can be substituted
- If X is a struct type, any type implementing all the methods of X and
containing all the fields of X can be substituted
I think the above specification solves the problem Robert mentioned:
for a template using a user defined type Foo, you can substitute any
type that implements Foo.
- If X is an array type, map type, or channel type, then any
array/map/channel type derived from X can be substituted.
That is:
type ArrType []int
can be substituted for
type T like []int
but not for:
type T like []int64
Based on the above, the following should also be meaningful within templates:
map<string,T>: this would be a map template whose values are
described by T.
[]like int : An array of int-like values
Function template is declared like this:
func F(a, b type T like (X, Y)) T
or if T is already defined as a type template:
func F(a,b T) T
An interface template can be defined like this:
type I interface_template {
F(a type T like(int)) T
}
A function with an interface template in its signature becomes a template:
func F(in I)
Need to work on some real examples to see how this develops...
>
> > 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.
