Re:Go 1.19 Released
by 62951413 on Tuesday August 02, 2022 @02:02PM
(#32322196)
At first glance I don't see anything done about migrating the standard library to use generics. Is there any roadmap? I remember a cascade of related improvements when Java introduced generics.
[ Parent
| on HN ]
The new generic atomic.Pointer[T] has been added[1]. More general improvements for slices and maps are being prototyped in the x/exp repos[2][3] to get it right and not get stuck with a sucky implementation in the stdlib.
[1]: https://pkg.go.dev/sync/atomic@master#Pointer
Re:Go 1.19 Released
by EscargotCult on Tuesday August 02, 2022 @02:57PM
(#32322846)
I think they've mentioned that they expect that their generics spec will evolve, plus they're waiting to see what idioms emerge before refactoring the standard library.
For now there are some experimental things in the exp module. See the maps and slices packages there. But yes, my understanding is also that they kind of waiting to see how generics work out. They've promised to make no breaking changes to Go v1, so adding any functions to the standard library is not to be taken lightly.
Re:Go 1.19 Released
by candiddevmike on Tuesday August 02, 2022 @03:17PM
(#32323063)
I think almost everyone is waiting to see those idiom too (myself included). If I'm going to rewrite stuff, I want to be able to justify it (less LOC may be be enough) and "do it right". Hopefully I get to see them in the sdlib soon!
That doesn't ever have to be done.
Generics are a language level feature, so it must be done at the language/compiler level, otherwise people are forced to implement it using "go generate" or other metaprogramming. The standard library doesn't ever have to change in that regard. If people want a generic version of some function, they can just write it themself. Its possible/likely that more generic functions will be added to standard library, but its not a foregone conclusion that it needs to happen, or even should happen.