rzgrep

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. That runs the risk of users processing items multiple times if they forget to check for errors. I would use either - a fresh new instance of T - a special instance of T created once (could be passed in to NewCBuf as a value with, to the user, obviously incorrect contents) 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.

I see, was under the influence of Java, where almost everything is an object reference. Now how do I return an error in the case that Pop is called on an empty buffer? I can return nil for a call on an empty buffer func (ctx *CBuf[T]) Pop() *T { but I could return any value for an error, and indicate with the second return value if the call succeeded. func (ctx *CBuf[T]) Pop() (T, bool) { I fixed the class, so now it looks as follows: https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/... Thanks! Still, I am feeling a bit uncomfy with returning a garbage value with the the error indication, even if that counts as being more idiomatic. I keep wondering, why golang doesn't have an Optional monad in its standard library, like they do everywhere else.

I used generics as an exercise: for a circular buffer [1] is that ok? The exercise project is a grep that greps through the content of archives [2] i needed a circular buffer to keep the last n lines for displaying the context of a match. [1] https://github.com/MoserMichael/rzgrep/blob/master/src/cbuf/... [2] https://github.com/MoserMichael/rzgrep