m4rw3r / chomp

A fast monadic-style parser combinator designed to work on stable Rust.
Apache License 2.0
243 stars 19 forks source link

Remove type parameter default on functions and methods #32

Closed bluss closed 8 years ago

bluss commented 8 years ago

See https://github.com/rust-lang/rust/pull/30724 and https://gist.github.com/nikomatsakis/760c6a67698bd24253bf

These are warnings in the nightly.

bluss commented 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.

bluss commented 8 years ago

This was of course contrary to my hope and the library API evolution use case I wanted to have available.

m4rw3r commented 8 years ago

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.

bluss commented 8 years ago

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!

m4rw3r commented 8 years ago

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.

bluss commented 8 years ago

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.