4 ms·

A good API should just accept either,e.g. the union of []byte and io.Reader. Both have pros and cons and those should be for the user to decide.

thayne 1y ago
Ah, but go doesn't have union types.
- Zambyte 1y ago
  One option would be to accept an interface{} and then switch on the type.
  - stouset 1y ago
    It's frightening how quickly the answer in golang becomes "downcast to interface{} and force type problems to happen at runtime".
    - throwaway894345 1y ago
      You don’t need to downcast to interface, io.Reader is already an interface, and a type assertion on an interface (“if this io.Reader is just a byteslice and cursor, then use the byteslice”) is strictly safer than an untagged union and equally safe with a tagged union. I wish Go had Rust-like enums as well, but they don’t make anything safer in this case (except for the nil interface concern which isn’t the point you’re raising).
    - wredcoll 1y ago
      Presumably the questions that have simple and easy answers don't get long comment chains.
  - throwaway894345 1y ago
    An io.Reader is already an interface, so you can already switch on its type.
    - Zambyte 1y ago
      My comment is explaining how > A good API should just accept either,e.g. the union of []byte and io.Reader. could be done. Can you elaborate on how the fact that io.Reader is an interface lets you accept a []byte in the API? To my knowledge, the answer is: you can't. You have to wrap the []byte in an io.Reader, and you are at the exact problem described in the article.
      - deleted 1y ago
        [deleted]
      - throwaway894345 1y ago
        I see what you’re saying. You’re correct that you can’t pass a []byte as an io.Reader, but you can implement io.Reader on a []byte in a way that lets you get the []byte back out via type switch (the problem in the article was that the standard library type didn’t let you access the internal []byte).
        ithkuil 1y ago
        An idiomatic way to approach this would be to define a new interface, let's call it Bytes with a Bytes() []byte method. Your function would accept an io.Reader but then the function body would typeswitch and check if the argument implements the Bytes interface. If it does, then call the Bytes() method. If it doesn't then call io.ReadAll() and continue to use the []byte in the rest of the impl. The bytes.Buffer type already implements this Bytes() method with that signature. By the rules of Go this means it will be treated as an implementation of this Bytes interface, even if nobody defined that interface yet in the stdlib. This is an example of Go's strong duck typing.
        Zambyte 1y ago
        That's really interesting, thank you for explaining that! Somehow I've never thought to implement interferences to describe types that already exist.
  - deleted 1y ago
    [deleted]
- foldr 1y ago
  You can just expose two different functions, one of which takes a byte slice and one of which takes an io.Reader. Given how the code works (it starts by buffering the input stream), the second function will just be a few lines of code followed by a call to the first. Perfect example of how complex type systems can lead people to have unnecessarily complex thoughts.
throwaway894345 1y ago
Nah, a good API doesn’t push the conditionals down. You don’t need to pass a union to let the user decide, you just need to present an API for each (including a generic implementation that monomorphizes into multiple concrete implementations) https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-down.html https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...

thayne 1y ago

Ah, but go doesn't have union types.

Zambyte 1y ago
One option would be to accept an interface{} and then switch on the type.
- stouset 1y ago
  It's frightening how quickly the answer in golang becomes "downcast to interface{} and force type problems to happen at runtime".
  - throwaway894345 1y ago
    You don’t need to downcast to interface, io.Reader is already an interface, and a type assertion on an interface (“if this io.Reader is just a byteslice and cursor, then use the byteslice”) is strictly safer than an untagged union and equally safe with a tagged union. I wish Go had Rust-like enums as well, but they don’t make anything safer in this case (except for the nil interface concern which isn’t the point you’re raising).
  - wredcoll 1y ago
    Presumably the questions that have simple and easy answers don't get long comment chains.
- throwaway894345 1y ago
  An io.Reader is already an interface, so you can already switch on its type.
  - Zambyte 1y ago
    My comment is explaining how > A good API should just accept either,e.g. the union of []byte and io.Reader. could be done. Can you elaborate on how the fact that io.Reader is an interface lets you accept a []byte in the API? To my knowledge, the answer is: you can't. You have to wrap the []byte in an io.Reader, and you are at the exact problem described in the article.
    - deleted 1y ago
      [deleted]
    - throwaway894345 1y ago
      I see what you’re saying. You’re correct that you can’t pass a []byte as an io.Reader, but you can implement io.Reader on a []byte in a way that lets you get the []byte back out via type switch (the problem in the article was that the standard library type didn’t let you access the internal []byte).
      - ithkuil 1y ago
        An idiomatic way to approach this would be to define a new interface, let's call it Bytes with a Bytes() []byte method. Your function would accept an io.Reader but then the function body would typeswitch and check if the argument implements the Bytes interface. If it does, then call the Bytes() method. If it doesn't then call io.ReadAll() and continue to use the []byte in the rest of the impl. The bytes.Buffer type already implements this Bytes() method with that signature. By the rules of Go this means it will be treated as an implementation of this Bytes interface, even if nobody defined that interface yet in the stdlib. This is an example of Go's strong duck typing.
        Zambyte 1y ago
        That's really interesting, thank you for explaining that! Somehow I've never thought to implement interferences to describe types that already exist.
- deleted 1y ago
  [deleted]
foldr 1y ago
You can just expose two different functions, one of which takes a byte slice and one of which takes an io.Reader. Given how the code works (it starts by buffering the input stream), the second function will just be a few lines of code followed by a call to the first. Perfect example of how complex type systems can lead people to have unnecessarily complex thoughts.

throwaway894345 1y ago

Nah, a good API doesn’t push the conditionals down. You don’t need to pass a union to let the user decide, you just need to present an API for each (including a generic implementation that monomorphizes into multiple concrete implementations) https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-down.html https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...