Here's one real life example that I came across recently.
I have a CRUD API that supports a bunch of different entity types. They all
support a superset of the same operations.
Each method represents a single HTTP call.
If the generics proposal was implemented, I'd be able to define a common
interface between them all.
Something like this:
type CRUD[Entity any] interface {
Find(ctx context.Context, filter Filter) ([]Entity, error)
FindOne(ctx context.Context, filter Filter) ([]Entity,
error)
Create(ctx context.Context, entity Entity) (Entity, error)
Update(ctx context.Context, entity Entity) (Entity, error)
Delete(ctx context.Context, id string) error
}
The Find operation allows the specification of a start-count window of
results to return.
It would be really nice to be able to define a generic function like this:
func FindAll[Entity any](api CRUD[Entity], filter Filter) ([]Entity,
error)
which would iterate return a slice of all the entities regardless of how
many underlying
calls to Find are needed.
Currently I can't easily do that. I could change the methods so that they
just returned interface
values instead of the respective entity types, but that would make the API
harder and more
error-prone to use. I could use reflection, but that code would be even
harder to read and maintain.
Currently I might end up using code generation, but that has its own issues
(I'd have to write
a code generator, or use some kind of template scheme, in which case the
actual source wouldn't
be amenable to gofmt and static checking).
cheers,
rog.
On Thu, 24 Dec 2020 at 06:15, Martin Hanson <greencopperm...@yandex.com>
wrote:
> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> 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/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>
--
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/CAJhgachY138vaOHWp90Zg6xV6QcqkTAhajGxXPCHWUQeaaz5kg%40mail.gmail.com.
