[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

Again, I'm mostly for generics being added to Go, because I've found occasion where they would be useful... On Thursday, July 20, 2017 at 6:40:00 AM UTC-7, M P r a d e s wrote: > > Go could have least have parametric functions (ex : > > func Foo(value T)T { /.../ } > > bar := Foo(3) //types are

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

In func Foo(value T)T { /.../ } It makes sense to anchor the definition of T to the func name. I feel like it is not needed, and i wonder about multiple T parameters. Where the question here is about func Foo(x , y ) (, ){} Or func Foo(x t, y u) (t, u){} At least, it is possible to say

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

Go could have least have parametric functions (ex : func Foo(value T)T { /.../ } bar := Foo(3) //types are verified at compile time, no need for reflection or interface {} on any runtime trick. ). But talking about this is kind of useless until Go rids itself of its over reliance on runtime

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

I think your example is not relevant, as it clearly intend to change the input type, the goal is to preserve it, while still working with its value. interface{} value type destroys the input type information, so you might have the opposite value type, a type that preserves. A type that let you

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

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