Replace default_stat in std::path with a Default impl for libc::stat

[MicahChalmer]

Instead of the internal default_stat function in std::path, make the stat structure implement Default and have the path code use that. Closes #9537. Alternative to #9637.

[huonw]

space

[lilyball]

This is going to conflict with my Path rewrite (#9655).

[alexcrichton]

As with a similar pull request recently, I feel like this suffers from the "making code less readable but more abstract" problem. It's really nice to call static methods on traits on type parameters, but it's not so nice to call static methods on traits directly.

If I saw let stat = Default::default() I wouldn't get nearly as much meaning out of it as let stat = stat::default_stat() or something like that. I may be one of just a few who feel this way, though, but I personally prefer to avoid invoking static methods directly on traits.

[lilyball]

@alexcrichton The problem is the stat struct is provided by libc. The default_stat() method is part of std::path::stat, which is really kind of sucky. It's not the right place to get a zero-filled libc::stat struct. So either add non-extern functions to libc, which is odd, or implement Default, which seems alright to me.

[alexcrichton]

Oh I agree that there should be some method of getting a zero'd out stat struct, I just feel like isn't the best way of going about doing this. It's still the problem of where the first question you ask is "how do I get a stat struct?" and when the answer is "Default::default" you start questioning your morals.

[MicahChalmer]

I think that the use of default to fill in missing fields is such a common pattern that it deserves a feature like the Default trait. But I agree that having to write Default::default() sucks. It seems straightforward to improve: all that would be needed is a standalone std::default::default function just like std::num::zero has: fn default<T: Default>() -> T { Default::default() }. You could then use default() where needed without having to mention the trait. (And in places where it's not obvious or inferable you'd have default::<stat>().)

Given that the usual answer to optional/named parameters is "use a struct," and given that there is special treatment for Default already (the "deriving" attribute) I also think both the Default trait and the aforementioned standalone default function should be added to the prelude.

Would that make it feel less immoral?

In any case, here I'm just trying to make it possible to use stat without writing separate code for each platform, while staying with the convention that is established in the code as it exists...

[huonw]

It seems straightforward to improve: all that would be needed is a standalone std::default::default function just like std::num::zero has: fn default<T: Default>() -> T { Default::default() }.

This is working around a language issue that should be resolved at the "source" (making calling static methods on traits more "sensible", how ever that is done) rather than continually papering over the symptoms by defining standalone functions.

[alexcrichton]

In my opinion, I think this should be closed in favor of #9637, #9537 would be wontfix, and #9637 would use re-exporting to expose the default stat function.

This would probably need more discussion for whether that's the best route to take, however.

[alexcrichton]

I'm going to close this an #9637 because I don't think that this is the right way to go about doing this. The stat syscall itself should not be getting used, and we don't want to encourage use of it. Instead the stat portions of rt::io::file should be getting used, and it's currently a legacy bug that the Path apis are still using these old stat structures (see #9958). Once we remove the consumers of those stat structures, then there's no need for this in libstd.

If it does end up being a large use case that external code needs to call libc::stat, then we can reconsider. For now it's still possible with a malloc and size_of, and it's certainly not the best interface but it gets the job done.