News for hackers. Stuff that matters.
Re:Go 1.20 Released by cpuguy83 on Thursday February 02, 2023 @03:28PM (#34632497)
Tacking on generics on a working code base is difficult.

I effectively used it in this little experimental CLI library: https://github.com/cpuguy83/go-cli/blob/main/command.go

It's pretty simple, but the nice thing is it can use any flag library you want (stdlib flag package, pflag, whatever).

Re:Go 1.20 Released by valyala on Friday February 03, 2023 @02:03AM (#34638045)
Try substituting F generic type with the FlagSet interface - and the code will become more clear without the need to use generics.
Re:Go 1.20 Released by cpuguy83 on Friday February 03, 2023 @01:09PM (#34645305)
That totally changes it as it requires type assertions to use. With generics `Flags()` returns a concrete type and not an interface.
Re:Go 1.20 Released by valyala on Friday February 03, 2023 @03:40PM (#34647437)
The question is whether the Flags() should return the concrete type instead of FlagSet interface? Another question is whether the additional complexity related to generics worth the ability to get the concrete type from Flags()?

In fact, the generic-free implementation based on the FlagSet interface is more flexible, since it allows storing multiple different FlagSet implementations in the same Cmd.

Re:Go 1.20 Released by cpuguy83 on Saturday February 04, 2023 @11:51AM (#34655838)
I mean the generic type def there could be changed such that different Cmd's can have different flag implementations.

The main point is that generics come in handy when building libraries so that you aren't forcing callers of your library into specific types or loosing some type safety.