6 ms·
There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any num
by grey-area 5y ago
There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any numeric instead of just float64, sort could be neater etc.
Perhaps a Go 2 if they ever get there could be a generic std lib rewrite, largely transparent to the end user, with some minor incompatibilities allowed and lots of stuff rewritten behind the scenes. They could remove a few ugly corners in the stdlib naming specific types by using generics, add a few more container types perhaps, deprecate some old stuff and move it out.
- hnlmorg 5y agoI'm hoping Go 2 replaces the file struct with an interface too. That's been a particular pain point for me.
- cpuguy83 5y agoYou mean like https://pkg.go.dev/io/fs#File https://pkg.go.dev/io/fs#File?
- hnlmorg 5y agoSorry I should have been more specific. I mean the os file struct https://pkg.go.dev/os#File https://pkg.go.dev/os#File The os package makes use of a *File struct rather than an interface. The authors acknowledged this was a mistake but it's some of the oldest code in Go and Go's backwards compatibility guarantee has meant that they cannot fix that. Since I author a $SHELL written in Go, being able to add in my own *File methods would have allowed me to add in some cool features. But I've found workarounds in most cases. It's just not as clean code as it could have been.
- cpuguy83 5y agoWhat I am saying is, there is already an interface, which os.File should be implementing.
- hnlmorg 5y agoAnd what I'm saying is that interface was created after os.File was created and after go 1.0 was released thus that change now cannot happen without breaking the backward compatibility guarantee. Hence my point about go v2.0
- deleted 5y ago[deleted]