slicy VS rzgrep

My personal experience with generics was to port a parallel circular queue library (used to take interface{} and require a type cast at every use) add an experiment to build all the Lodash slice and collection functions in Go.

Happy to say that both worked really well. Took me less than an hour to understand the system enough for these purposes, and the implementation hides neatly in the library - the code that uses the library has absolutely no mention of anything generic. Having generics also helped switch to cleaner implementation inside as well, because I could now use maps as well without type casts.

Looks like a solid useful system - I could do everything I wanted, all the complexity stays in the library, and changes were pretty minimal and easy to understand. Would recommend.

https://github.com/sudhirj/cirque

https://github.com/sudhirj/slicy

I think so, too, but only because that’s idiomatic go. In general, it’s not a good idea to have functions that logically return a value or an error return a value and an error. If you use go, that’s what you do, though.

I see that that was changed already (https://github.com/MoserMichael/rzgrep/commit/764b9ad61a5dbe...)

I think I would not return “ctx.data[0]” for the value returned in case of error, though, but either

- a fresh new instance of T

- a special instance of T created once

The first is cleanest, but may not be performant if creating T’s is costly.

The second may be risky if the returned items are mutable and the caller changes them.