While I lean towards the view that Go should add support for type generics, 
I'm not sure your example actually provides sufficient detail to be an 
argument for them.

On Monday, July 17, 2017 at 2:07:46 AM UTC-7, mhh...@gmail.com wrote:
>
> in func do(i interface{}) interface{} (return i), do says nothing because 
> "interface{} says nothing", 
>
> from the caller pov, it looses information at the return call, 
>
> var x = "o"
> do(x) // <- return lost the track it was a string
>
> if you delegate that func to another func, 
> it can t says anything else rather than nothing unless it introduces type 
> assertion.
> func to(do func(interface{})interface{}) func (interface{}) interface{} { 
> return func (i interface{}) interface{} {return do(i)} }
>
> if the observation become "interface{} destroys information", 
> does it make sense to consider a "value type of any type that carries out 
> its input type" ?
> func do(any <t>) <t> {return any}
> do("thing") <- this is explicitly string
>
> Acting the same way as interface, except that little thing about 
> destroying/preserving an information.
>
> It can be delegated to func that works on anything, still returns concrete 
> types.
> func to(do func(*<t>*)<t>) func (<t>) *<t>* { return func (i <t>) <t> 
> {return do(i)} }
>
> to(do)("whatever") // got a string, right ?
>
> One step forward, 
> what if <t> might be able to say "any type with a constraint on that 
> interface",
> func do(any <t:Stringer>) <t> {return any}
> do(WhateverStringerCapable{}) <- much like using a regular parameter of 
> type Stringer/interface{}, but now the return call reflects the invoke call 
> , so its more complete than interface{}/Stringer.
>

If the "do" method takes and returns a Stringer, then why not just declare 
it that way? To make this a more interesting discussion, you have to get 
into the details of what the "do" function actually needs to do? Why can't 
it just use standard interfaces?

As I see it, one of the generics problems comes from using the built-in 
slices and maps. As it current stands, if I create a method:

func concat(foo []Stringer) String {
    result = ""
    for _, s := range foo {
        result = result + s.String() + ";
    }
    return result
}

but suppose I have two structs, Foo, and Bar, and both *Foo, and *Bar 
implement Stringer.

I cannot do this:
func myFunc(f []*Foo, b []*Bar) string {
    return concat(f) + concat(b)
}

This seems like a more concrete scenario than the one you identified.

Eric.
 

>
> no?
>
> Or maybe there is a reason in destroying that information ?
>

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