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
custom implementations #14
Comments
I think I will start this as a completely separate library - if it works out, we can see if it makes sense. |
Yes. That's my observation too. But I don't have a time to do it myself. So yes, please start it as a separate library. It's good idea besides the error handling. |
Ok, I already started this. Now I am stuck at the generalized problem of FIND_IMPL (instead of FIND_DESCRIPTION_IMPL, etc.). So in a simplified version, I want to do a search via macros macro_rules! enum_transform{
(FIND $needle:ident
{$pop:ident $( $hay:ident )*}
) => {
// PSEUDO-CODE >>
if($pop == $needle) {
true
} else {
enum_transform!{FIND $needle {$( $hay )*}
}
// << PSEUDO-CODE
}
(FIND $needle:ident {}
) => {
false
}
}
assert_eq!(enum_transform!(FIND bar {foo bar baz}), true); This can partly be reduced to this problem:
Which rust macro is capable to do this check on the AST-level? Of course I can do something like macro_rules! equal{
($a:ident $b:ident)
=> { stringify!($a) == stringify!($b) }
} Rust should be able to reduce this to true booleans at compile time - but strictly after the macros have completed. I believe this would not solve all problems, because the compiler would probably complain about invalid expressions, even if they are unreachable like this if equal!(foo bar) {
// .. invalid expressions - rust would still complain, although they are unreachable
} Even if it worked, I would not like this workaround very much. Hm. This could be a show stopper. What do you think? |
Hm. I should try if macros can dynamically define new local macros and call them. I dont know if Rust allows that, if so, it would be very powerful. |
Ok, after playing around with this: This works in general - which is astonishing, given the limitations of macro_rules. But there are two very big drawbacks doing this whole thing with macro_rules!
Takeaway: I think this should better be done with a procedural macro - but there is currently no way to write procedural rust macros for the stable toolchain. So I think this must wait until the macro reform. Btw - This is how far I got: https://github.com/colin-kiegel/enum-transform/blob/master/src/macros.rs. I think this is a dead end for above reasons - but at least I learned a lot about rust macro_rules!. :-) |
Observation: The main pain point of enums is the repetitiveness of match-statements. Which are scattered around at different locations. This is good for adding and removing a new trait implementation (which is a local change of code). But it is not good for adding and removing enum-variants. Quick-error does code transformations to invert this for a specific set of traits.
Here is the (possibly crazy) idea: What about a code transformation that is generic in terms of the traits, too - like this example
IN
OUT
If we had such a generic enum_transform macro, then
(a) quick_error could be rewritten in terms of enum_transform AND
(b) quick_error could itself could allow generic substitutions like this
EDIT:
The text was updated successfully, but these errors were encountered: