Consider tweaking client options a bit #388
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
priority/backlog
Higher priority than priority/awaiting-more-evidence.
I believe (been mulling this over a bit) that we can make it so that client options don't require different functions when the same option occurs, but the trade-offs are a bit strange in terms of compatibility. TL;DR is that we define an interface to accept as options instead of functions, and then structs can implement multiple different interfaces.
The downside is that the options functions now return a concrete type, which means that type is now part of the public interface, despite being a bit of an implementation detail. The alternative is returning an umbrella-interface, but that means that every time we add an element, it's a breaking change (since the function signature changes).
The text was updated successfully, but these errors were encountered: