Closed bluss closed 8 years ago
I don't know exactly where these discussions were, but the language team wants to basically back out of the type parameter defaults feature for functions altogether. It makes sense to remove these while they are still duds.
This was of course contrary to my hope and the library API evolution use case I wanted to have available.
I can see why they want to remove it, it is an extra feature which might not be needed. Maybe the working related to HKTs could shed some light on what is needed (I assume that some type-defaults would be really neat to have there). But I am still a bit surprised that types and traits are treated differently compared to functions.
if functions were treated like struct and trait then:
fn id<T=u32>(t: T) -> T { t }
id(2); // calls id::<u32>()
id("hi"); // tries to call id::<u32>() and produces an error
id::<&str>("hi"); // ok
which is very limited!
Wouldn't the above example with id("hi")
still infer to id::<&str>("hi")
? From the small tests on play.rust-lang.org it seems like struct Id<T=u32>(T)
behaves identically to fn id<T=u32>(t: T) -> T { t }
with the excption of the wrapper itself.
True, the Id(xyz)
constructor will be generic that way. I was thinking of the way you name the type, so for example in fn default() -> Id
and let x: Id
, the default is used.
See https://github.com/rust-lang/rust/pull/30724 and https://gist.github.com/nikomatsakis/760c6a67698bd24253bf
These are warnings in the nightly.