-
Notifications
You must be signed in to change notification settings - Fork 14
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
Suggestion: Make group traits more "rusty" #5
Comments
I think that would be a welcome change, although not an urgent one. Also, does element need the One other comment - I usually prefer having an |
Unclear to me, it seemed that there was some wish to make this more abstract.
Unfortunately that is not really a good way though for traits, as traits are meant to be open, to be implemented, but an enum is closed. |
Yes a
I wanted to use that in the first place but it ended up being very difficult with all the different traits and so on. And to be honest, I've taken inspiration from how zexe code did it and it does like that also. @dignifiedquire Even though statistically it does seem complicated, can we have a way though to detect which type an error is dynamically ? |
Ah, right! Of course Element needs a type parameter. Then I'm curious about the choice of having a default of Self :) |
Just to avoid specifying it for |
You can use an associated type in the error which is generally the standard approach to this. Zexe's usage of the Also I recommend using |
Concrete error types are implemented in #30, cc @nikkolasg @dignifiedquire |
|
I'll be adding implementations for the `std::ops traits tomorrow. |
FWIW implementing this for |
@gakonst I have been wanting to add |
I went through the current group traits and this is what I came up with, how they could fit better into the rust trait system
Let me know what you think
The text was updated successfully, but these errors were encountered: