Default::default() is a normal part of the language. It's in the Rust book. It's in the std docs. It's everywhere. It works fine.
Rust uses type inference, and it's very common for Rust programs not to write out actual types they work with. It's very normal for Rust programs to use complex types that are inferred in very complex ways (e.g. iterator chains with closures). It's part of the core design. Trade-offs of this have been considered and accepted long time ago.
If anything, T::default() gets used because it's shorter than Default::default(). There's an unstable fn default which exists to make it possible to just write default(), even. It's a fairly common request to be able to use path::to::Trait::function; to be able to write function() instead of Trait::function(); the example almost always used in this request is Default::default.
So yeah, while it's not uncommon for people to prefer T::default() over Default::default(), it's at least as not uncommon for people to use Default::default().
If you've ever seen/used .collect() or .into(), it's the exact same inference of generic return type as with Default::default(), but even more inconvenient to avoid relying on inference backflow.
And yet the Rust Quiz uses type inference for several of its questions, simply as a way to get behaviours that are challenging to understand.
IME, people do end up writing out types because type inference doesn't do what they expect - thus, adding a new way for inference to surprise you needs justifying not in terms of "yeah, we have inference already, so you can already surprise yourself with it" but instead in terms of "this particular form of inference benefits much more than it hurts, and it'd be worthwhile even if we didn't have as much inference as we do already".
Remember, we're (by definition) not talking about the existing ways Rust uses inference, but we're saying that we're going to change something that currently isn't inferred to something that is. This is similar in potential impact to saying that we're going to infer function signatures from the body of the function in some cases (e.g. where the function is private); yes, it'll help in many cases, but it'll also hinder in others, and the resulting tradeoff is different to today's tradeoff.
IME, both .collect() and .into() are usually seen in places where the type is (at least partially) written out by hand. In other words, it's rare to see let foo = i.collect();, but more common to see let foo: Vec<_> = i.collect();, precisely because type inference can surprise you.
Given this, rather than just saying "well, there's room to make mistakes in Rust already, so we're not going to consider whether or not this new change can make it more or less likely to write buggy code", I'd prefer to see people justify the feature in its own right. The existence of similar features can be useful to say "no, this doesn't fit in with existing Rust usage, and it's clearly going to create new bugs", but those features do not act to justify this just because there's existing ways to write bad code.
That said, we're getting close to going round in circles. I'm going to disengage unless I see new points being raised.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.