-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] new cats.more
module
#1940
Comments
I'm not convinced this is justifiable for any technical reason, but there may be a benefit in a "restrained" core just to keep the intimidation level down. However if we do this I would like it to be clear that it's not a bunch of random crap, but rather additional features that are less-commonly used. As for naming I kind of like |
I love the idea of naming it |
cats.extra
modulecats.more
module
I'll also refer to #1364, as it also has some type classes that seem like they could go into |
Relevant discussion can be found here
I am proposing creating a
cats.more
module (could be a separate repo) where we can place in non-core, no-so-complex features. Possible candidates for going into this module includes #1935, #1812, #1767, #1755, #1730, #1400, #921, #324(We shall still decide separately for each of these cases IRT where they should actually go)
It's for stuff that we can’t justify a single module for it and can’t find where it belongs. The API should still be stable to be included in this module though. We may or may not want to provide the same backward compatibility promise with this module as with
core
Update: Renamed from "extra" to "more"
The text was updated successfully, but these errors were encountered: