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

Add utility function that just calls Default::default. #18934

Closed
wants to merge 1 commit into from
Closed

Add utility function that just calls Default::default. #18934

wants to merge 1 commit into from

Conversation

blackbeam
Copy link
Contributor

No description provided.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

@ghost
Copy link

ghost commented Nov 13, 2014

@blackbeam Thanks for the PR! Could you please provide some rationale for this change as it's not immediately obvious? Default::default() is expected to be used sparingly and a static method on a trait can be used anywhere a regular function can, for example:

use std::default::Default;

fn main() {
    Some(42u).unwrap_or_else(Default::default);
}

If there's no pressing reason for the free-standing function, I don't think we should add it, to be honest.

@blackbeam
Copy link
Contributor Author

The problem appears when i need to use it in some way in macro_rules.
I can't just write Default::default::<$ty>() cuz there is no tipe parameters and i have something like this as a result (example from rust's libcollection):

macro_rules! t (
    ($ty:ty) => {{
        let v: $ty = Default::default();
        assert!(v.is_empty());
    }}
);

The point was not to add another shortcut function but to provide type parameter:

macro_rules! t (
    ($ty:ty) => {{
        assert!(default::<$ty>().is_empty());
    }}
);

@ghost
Copy link

ghost commented Nov 19, 2014

@blackbeam Thank you for the clarification!

Your PR is much appreciated but I don't think the rationale for this function is significant enough for it to be added, therefore I don't think the PR is going to be accepted. You would almost never see Default used in contexts where it was impossible to infer that trait's implementor. And when you do, as in your example, I think it's okay to use the extra let to help inference.

ccing @aturon just to make sure.

@Gankra
Copy link
Contributor

Gankra commented Nov 19, 2014

I do think it would be nice to be able to use something shorter than Default::default(), but richer use statements or sugar for using Default would be a better long-term solution.

@aturon
Copy link
Member

aturon commented Nov 20, 2014

@jakub- @gankro I completely agree.

@blackbeam Thanks again for the PR. I'm going to go ahead and close it for now.

@aturon aturon closed this Nov 20, 2014
lnicola pushed a commit to lnicola/rust that referenced this pull request Jan 20, 2025
…m_into

feat: Add the ability to jump from `into` to `from` definitions
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

Successfully merging this pull request may close these issues.

4 participants