It’s early days and the API is likely volatile, ideas and contributions are welcome. Have a look at the design principles below. Feel free to open an issue, send a pull request, or ping Matt Sherman @clipperhouse.
Design principles for contributors
It’s intended to fit well with idiomatic Go. Explicitness and compile-time safety are preferred. For this reason, we are not using interfaces or run-time reflection. (Though if a good case can be made, we’ll listen.)
The goal is to keep the API small. We aim to implement the least number of orthogonal methods which allow the desired range of function.
It’s about types. If something would be expressed <T> in another language, perhaps it’s a good candidate for gen. If it would not be expressed that way, perhaps it’s not a good candidate.
We avoid methods that feel like wrappers or aliases to existing methods, even if they are convenient. A good proxy is to imagine a user asking the question ‘which method should I use?’. If that’s a reasonable question, the library should be doing less.
These guidelines are not entirely deterministic! There’s lots of room for judgment and taste, and we look forward to seeing how it evolves.