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 v
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 your v
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 f
...I have not been able to find it meaningful elsewhere.
sorry, i forgot,
- ultimately, type D struct {r}, does not make sense either
imo.
On Thursday, July 20, 2017 at 6:21:21 AM UTC+2, mhh...@gmail.com wrote:
>
> I think your example is not relevant, as it clearly intend to change the
> in
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
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 say
