In func Foo<T>(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 <t>, y <u>) (<t>, <u>){}
Or
func Foo<t,u>(x t, y u) (t, u){}
At least, it is possible to say your version has more impact on the overall
syntax than my initial proposal,
because using your version there will be new things like
bar := Foo<int>(3)
In my proposal, because 3 is an int, <t> is solved.
another very questionable thing,
if you have <t:string> (basic type), you can return only a (string), or
destruct it into another type (strconv.Atoi).
that happens because string does not match any interface, its basic.
So f(<t:string>) seems totally useless and redundant to f(string).
<t:Constraint> is really interesting with structs and interfaces,
because struct can have as many facets as there is interface it satisfies.
- its open for the caller, you can inject and receive any type that
satisfies the contract
- closed to the declarer, it must become a meaningful type before you
actually interact with it
________________
Aside of this, i have lots of troubles to write the clear distinction
between interface{} and interface.
I d really like we had another keyword like *contract* to define an
interface.
or empty{} rather than interface{}.
Anything that get rides of this naming problem.
On Thursday, July 20, 2017 at 3:40:00 PM UTC+2, M P r a d e s wrote:
>
> Go could have least have parametric functions (ex :
>
> func Foo<T>(value T)T { /.../ }
>
> bar := Foo<int>(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 features like reflection. I suspect Go reflection
> capabilities are why the language stopped evolving significantly at first
> place. String tags are another symptom of that "disease".
>
> It's possible to write the snippet above with reflection today
> (reflect.MakeFunc) , it shouldn't be.
>
>
>
--
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.
