A good compromise would be to only implement "parametric" functions. append
and make are" parametric" functions as they know what is their return type
at *compile time , *no matter what type the array/slice argument is . That
way people who don't want a generic type are happy as no generic type is
introduced, and people who want to write functions like push/pop/map on
arrays of any type in a type safe way.
Go is full of compromises of that sort so it shouldn't be an "all or
nothing" debate.
Aside from the implementation, the most difficult matter is choosing the
right syntax, such as
func XOR<T>(array1 []T,array2 []T)array[]T{
// implementation
}
So yes, people would not be able to define their own type of container
(set,queues,binary trees,...). But all these containers can be build from
array or map structures and methods specific to each data structure could
now be written in a "generic" way.
At the end of the day we all want the same thing, *compile time type safety*,
no more, no less.
Le mercredi 15 juin 2016 03:04:05 UTC+2, xingtao zhao a écrit :
>
> Here is my proposal for generic in go:
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the
> proposal, I want to keep back compatibility. And I try to add the
> orthogonal feature only and keep the language still simple enough.
>
> Please add your comments on it. Hope it is useful and could inspire some
> new features in go 2.0
>
> Thanks!
>
--
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.
