rustc: inference for numeric literals does not take default type parameters into account

[aturon]

The following code fails to compile:

#![feature(default_type_params)]

fn foo<T = u64>(t: T) {}
fn main() {
    foo(0);
}

with

error: cannot determine a type for this expression: cannot determine the type of this integer; add a suffix to specify the type explicitly

despite the fact that the actual type is determinant.

Fixing this problem could help mitigate problems with the int fallback: for functions like range, we could provide a default type parameter of, say, uint while retaining flexibility for other types. (Doing so loses some of the benefit of the fallback removal, but we can introduce defaults in a controlled way.)

[aturon]

cc @wycats, @brson, @alexcrichton

[alexcrichton]

This seems like it would be nice to have, especially for the range case. If we were to push forward with it, we may want to consider making default type parameters a full-fledged feature of the language, promoting them out of a feature gate.

[thestinger]

A pointer size integer doesn't make much sense as a default for range. It varies in size per platform and will cause lots of problems on 32-bit since developers aren't going to be using it.

[aturon]

@alexcrichton I think we should probably push for un-feature gating anyway, as we're using this feature in other important places in std already.

@thestinger The uint choice was just an example, not carefully thought through. But the key point is, unlike the int fallback, we can make choices about defaults that vary depending on the context.

I do think that providing a default for range would recover a lot of the ergonomics of the int fallback, though. Do you think that proving any default for range is a bad idea? Or just that we should pick a fixed-side default?

[eddyb]

I tried implementing a more general form of this, and it's not that hard to hook it up to our existing inference infrastructure.
Sadly, #13702 didn't get any kind of feedback, not even a mention about requiring an RFC.

[aturon]

@eddyb :( I'm sorry to hear that.

I've spoken to @nikomatsakis about the general idea of using default type parameters as a fallback, and he seems to think it's a good idea. If you'd like, we could collaborate on an RFC and then try to revive your PR.

[aturon]

@eddyb Relatedly, I would like to push to un-feature gate default type parameters, as they are proving useful in multiple places in libstd. I think your work in allowing them to work as a fallback will be an important step.

[sanxiyn]

What happened to this?

[ftxqxd]

AIUI, rust-lang/rfcs#213 proposes this feature, but hasn’t been merged yet.

[steveklabnik]

This code now compiles.

[eddyb]

It only compiles because we default to i32 - presumably you want to use size_of_val or something similar to check the type.

[bltavares]

Triage: the OP's code compiles fine on nightly with many warnings:

warning: this feature is stable. attribute no longer needed, #[warn(stable_features)] on by default
 --> <anon>:1:12
1 |> #![feature(default_type_params)]
  |>            ^^^^^^^^^^^^^^^^^^^

warning: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions., #[warn(invalid_type_param_default)] on by default
 --> <anon>:3:8
3 |> fn foo<T = u64>(t: T) {}
  |>        ^
warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
note: for more information, see PR 30742 <https://github.com/rust-lang/rust/pull/30724>

warning: unused variable: `t`, #[warn(unused_variables)] on by default
 --> <anon>:3:17
3 |> fn foo<T = u64>(t: T) {}
  |>                 ^

On stable, without the feature pragma, the warning on default for functions will be a hard error in future release, as mentioned on the nightly warnings.

[leoyvens]

@Mark-Simulacrum I think this issue can be closed as a subissue of #27336, the fate of this will be decided by what we do with that RFC. It's certainly not "just a bug".

[Mark-Simulacrum]

Yeah, that's true. Thanks -- closing.