Skip to content
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

Feature request: Ability to call functions on members, e.g. PathBuf::display() (was: How to display path members?) #11

Open
matthiasbeyer opened this issue Dec 16, 2020 · 6 comments

Comments

@matthiasbeyer
Copy link

Consider:

pub struct Some(PathBuf);

How to derive Display for it? Is there some way to specify that the code needs to call .display() on the member?

@frozenlib
Copy link
Owner

There is no way to display anything other than the field.

I hope to be able to implement Display by calling method at some point.

@matthiasbeyer
Copy link
Author

Okay, thanks for the fast reply!

Shall I close this, or leave it open as a feature request?

@frozenlib
Copy link
Owner

I would like to close this issue after making it possible to use a method call, so please leave it open.

@matthiasbeyer matthiasbeyer changed the title How to display path members? Feature request: Ability to call functions on members, e.g. PathBuf::display() (was: How to display path members?) Dec 16, 2020
@nyuichi
Copy link

nyuichi commented Nov 18, 2021

I would like to use this feature for displaying members of Vec<T> type.
In particular I want to use it together with the unstable intersperse method like below and IIUC currently there is no way to write something like this using this crate.
Implementing only the feature discussed on this thread does not help to improve the readability a lot, though.

#[derive(Display)]
#[display("{(0.iter().map(|data| data.to_string()).intersperse(", ".to_string()).collect::<String>())}")   // strawman syntax
struct Foo(Vec<u32>)

@frozenlib
Copy link
Owner

It might be nice to support a syntax for repetition, such as $(...),+ in macro_rules! or #(#var),* in quote crate.

@norcalli
Copy link

norcalli commented Aug 18, 2022

It occurs to me that having any way of doing this right now would also let us handle Option types, even if it is more verbose. At the very least, there is some way of solving the problem, whereas currently, there are cases where parse_display just can't be used.

This seems like the escape hatch that can make it usable almost everywhere.

And it would be nice to have a function specification support for from_str too.

As far as syntax and readability goes, I don't think it's a problem, because if your expression is that complex, you should just make a function and call it instead. e.g. #[display("{0:my_display_function(_0)}")]. I think it's sufficient for the expectation to be that function returns something that is Display, since there are ways of avoiding allocation in that case too.

e.g. this helper I have in my personal std:

pub struct FmtFn<F>(pub F)
where
    F: Fn(&mut std::fmt::Formatter<'_>) -> std::fmt::Result;

impl<F> std::fmt::Display for FmtFn<F>
where
    F: Fn(&mut std::fmt::Formatter<'_>) -> std::fmt::Result,
{
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        (self.0)(f)
    }
}

pub fn example(x: bool) -> impl std::fmt::Display {
    FmtFn(move |fmt| write!(fmt, "Hi: {x:?}"))
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants