On 30-12-2020, robert engels wrote:
>
> --Apple-Mail=_053BD88E-EE7F-423A-AE3D-712B500390F8
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="UTF-8"
>
> Agreed.
>
> I had proposed a different approach, where the built-in map and slice could=
> have alternative implementations chosen during make(). 95% of generics usa=
> ge is collections. I think this would have retained the simplicity of Go a =
> bit better than generics - but at the end of day - generics are not =E2=80=
>=9Cdifficult". Bad programmers write bad code without generics.
If 95% of generics are collections the current draft is overkill.
What about a simplified version with only one generic type (like we do
with interface{}), without constraint as long as it can compile ?
func add(x, y GenericType) GenericType {
return x + y
}
add(1,2) // add can compile : func add(x, y int) is generated
add("abc", "def") // can compile : func add(x, y string) is generated
add(1, "abc") // two differents type : error
GenericType will be like interface{} but instead of casting it'll
generate on the fly, at compile time the function with the type of each
functions call.
I believe it's too easy and i miss something already discussed...
--
wilk
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/rsk0bb%24tg6%241%40ciao.gmane.io.
