-
Notifications
You must be signed in to change notification settings - Fork 35
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
Remove display/description boilerplate for simple error wrappers? #3
Comments
Probably it may look like:
I.e. the important thing it that it should be easy to add additional variant that isn't a simple wrapper, but provides additional information. I'm not sure about good name for On the other hand, I usually use something like:
I'm not sure what the best practice is, but I have two reasons:
|
I see, but in my case I'd end up with console output like Is there a way to let the user use their own macros inside the quick_error macro? That may solve this problem as well. |
I agree that using quick_error can involve a lot of unnecessary repetition. @tailhook's code above demonstrates this:
Here,
¡Ay, caramba! So much typing! So here's some suggestions for improving this
With the above, my error variant would now look like:
Much more succinct Which when displayed, would look something like |
Yeah. I was thinking about using docstrings too. The issue is that we don't have a good parser for docstrings. This means we can either use all the lines in the docstring or the first one. Using all the lines from a docstring would probably lead to shortish doc comments without good description of the error. And using just first line means you can't wrap it. I'm not sure this is a good thing either. So, I'm kinda having mixed feelings for now. |
Assumption: Parsing of comments would probably mean additional recursions of the current macro. Those recursions are limited by a setting of the compiler. The macro can only parse enums of certain length / complexity for any given recursion limit (without further trickery). This "ratio" would probably decline. With libmacro becoming stable this limitation will be gone. Until then, quick-error should be very conservative about using further recursions. I would postpone this until stabilization of libmacro, if the assumption is true. |
Currently I have code that looks like this:
I see a few options to remove that boilerplate:
from()
set those defaults automatically for simple wrappers.The text was updated successfully, but these errors were encountered: