-
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
Support access to std::fmt::Formatter inside display for more flexibility #13
Comments
Well, at least But your examples do not demonstrate real purpose of the thing. There should be no additional logic in the display handler, except displaying the data. Also I'm not inclined to add every feature that may ever be possible to do here. We need only about 80%, and I think we have already covered about 99% :) May be we should have a way to opt-out the Display implementation here, so you can implement the trait yourself? |
You are right about the argument order. The purpose in this case would be to write some additional data only in some cases, like if let Some(x) = reason {
try!(write!(f, " {}", x));
} At least that was my use case - I agree, it is not super important. |
Also want this in two different cases:
My(e: MyError) {
display("{}", match e {
&MyError::DontDisplay{..} => &e.description() as &fmt::Display,
_ => e as _,
})
} |
@jethrogb For the second one, yes, I think it might be helpful. Would you like to make a PR? |
It would be nice to implement display via direct access to the std::fmt::Formatter - as another option. This would allow additional logic inside the display logic without temporary buffers.
Use case: Complex enum-variant with
Option<...>
fields.At first I was thinking about closures, but this would require to capture all fields explicitly - not so nice. Instead I suggest we provide it like
display(f, me) -> { /* ... */ }
.Suggested Grammar (example)
Current Workaround - needs redundant allocation for temporary buffer
EDIT:
The text was updated successfully, but these errors were encountered: