3 ms·

I think they're using it so that they can use nil as the zero value to indicate the buffer is empty in cases where the zero value is a valid result. I feel lik

I think they're using it so that they can use nil as the zero value to indicate the buffer is empty in cases where the zero value is a valid result. I feel like the comma ok idiom is a better idea here.

Someone 5y ago
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/764b9ad61a5dbe6b23c97ce739ed770199e222c5 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.
- MichaelMoser123 5y ago
  > think I would not return “ctx.data[0]” for the value returned in case of error, though. I am not to comfortable with this either, i wonder why golang doesn't have a Maybe/Option monad in its standard library, i mean that's a very widely used pattern, nowadays... or am I missing something here? Maybe/Option monads in other languages: https://www.scala-lang.org/api/2.13.3/scala/Option.html https://www.scala-lang.org/api/2.13.3/scala/Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe I guess they didn't want to copy the T value into the Option instance, but yeah, otherwise you get something like this, or you have to return a pointer.
  - Someone 5y ago
    In C-like languages pointers are the Maybe/Option type. Go has that. The go error pattern would need Either, though. In C, that’s ‘union’, but go (rightly so, IMO) didn’t copy that. Problem is, once you have Either[T,U], you want Either[T,U,V] and then, you want pattern matching. That, like generics, complicates a language. The go developers don’t want to go there (¿yet?).
    - MichaelMoser123 5y ago
      > In C-like languages pointers are the Maybe/Option type. I think that's a bit of a stretch, operations on Maybe types can be chained or used with Java streams. You can't do a thing like that with pointers. They could have dome something like java streams, given that golang has lambdas, but I guess that would not be idiomatic, or something like that... You do have a point with pattern matching, they don't do that in go. Scala has it, Java is getting pattern matching as some recent addition, but they added the Optional type with java 8.
      - Someone 5y ago
        Yes, it’s a bit of a stretch, but C-like languages don’t have objects you can call methods on, so they do not have call chaining.

Someone 5y ago

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/764b9ad61a5dbe6b23c97ce739ed770199e222c5 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.

MichaelMoser123 5y ago
> think I would not return “ctx.data[0]” for the value returned in case of error, though. I am not to comfortable with this either, i wonder why golang doesn't have a Maybe/Option monad in its standard library, i mean that's a very widely used pattern, nowadays... or am I missing something here? Maybe/Option monads in other languages: https://www.scala-lang.org/api/2.13.3/scala/Option.html https://www.scala-lang.org/api/2.13.3/scala/Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe I guess they didn't want to copy the T value into the Option instance, but yeah, otherwise you get something like this, or you have to return a pointer.
- Someone 5y ago
  In C-like languages pointers are the Maybe/Option type. Go has that. The go error pattern would need Either, though. In C, that’s ‘union’, but go (rightly so, IMO) didn’t copy that. Problem is, once you have Either[T,U], you want Either[T,U,V] and then, you want pattern matching. That, like generics, complicates a language. The go developers don’t want to go there (¿yet?).
  - MichaelMoser123 5y ago
    > In C-like languages pointers are the Maybe/Option type. I think that's a bit of a stretch, operations on Maybe types can be chained or used with Java streams. You can't do a thing like that with pointers. They could have dome something like java streams, given that golang has lambdas, but I guess that would not be idiomatic, or something like that... You do have a point with pattern matching, they don't do that in go. Scala has it, Java is getting pattern matching as some recent addition, but they added the Optional type with java 8.
    - Someone 5y ago
      Yes, it’s a bit of a stretch, but C-like languages don’t have objects you can call methods on, so they do not have call chaining.