-
Notifications
You must be signed in to change notification settings - Fork 415
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
feat : derive DecidableEq
for mutual inductives
#2591
Conversation
Thanks for your contribution! Please make sure to follow our Commit Convention. |
awaiting-review |
|
I was slightly surprised to find that writing |
Would you mind adding a sentence about this to |
I was surprised by this behaviour too ! As it turns out, other handlers share the same behaviour, so I figured I shouldn't change it here. Another thing that surprised me is that deriving on one inductive doesn't lead to the other one(s) also getting the instances generated. Furthermore, you can't use |
External Contribution Guidelines.
This partly implements #2329 by making the derive handler manage mutual inductive types. The general framework for derive handlers is currently not well-suited to manage nested inductives without resorting to making the derived instances partial, and managing them would require big changes to the framework, and thus, to other handlers as well. Such work/design decisions should be discussed in a subsequent RFC.