Tracking Issue for _ as a const argument: feature(generic_arg_infer)

[JulianKnodt]

This is a tracking issue for the RFC GenericArg::Infer
The feature gate for the issue is #![feature(generic_arg_infer)].

What is GenericArg::Infer?

Currently, rustc supports type inference. That is, given a function fn(T), it can infer the type of T based on its usage. Const-generics also has limited support for inference, such as for arrays, we can infer N: usize in some usages [T; N]. In order to expand inference for consts, it's necessary to lift the current specialized type Ty::Infer into GenericArg::Infer, as GenericArg covers both consts and types, whereas Ty::Infer can only be used in the place of types. This will eventually allow for consts to be inferred in all the same locations as types.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (Add hir::GenericArg::Infer #83484)
• Solve generic_arg_infer impl is prone to bugs in hir visitors #112110
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Should hir::Ty::Infer be removed?

Implementation history

[varkor]

@JulianKnodt: could you add a short description of what this tracking issue concerns, for anyone who is unfamiliar with this feature?

[JulianKnodt]

@varkor Done, let me know if it makes sense

[varkor]

@JulianKnodt: that looks good, thanks!

[leonardo-m]

The first step was done

[c410-f3r]

Any news about this feature?

[JulianKnodt]

It's currently unstable and no work has been done on it that I know of

[ghost]

@JulianKnodt why hasn't this landed yet? Sounds like the implementation is done.

[Rua]

What's the progress on this?

[ExplodingWaffle]

Apologies if this is the wrong place- I think this has to do with this feature, but it might actually be a broader issue.

See this code (playground):

#![feature(generic_arg_infer)]

trait Register<const N: usize>: Default {}

#[derive(Default)]
struct Test([u8;4]);

impl Register<4> for Test {}

struct Accessor();

impl Accessor {
    fn default<R: Register<{N}>, const N: usize>(&mut self) -> R {
        Default::default()
    }
}

fn main() {
    let mut regs = Accessor();
    let test1: Test = regs.default();
    let test2 = regs.default::<Test, _>();
    let test3 = regs.default::<Test>(); // :(
}

I’m wondering about the limitation(?) that makes test3 a compile error- in test1 the compiler doesn’t need any help with the generic (though it would if you added, say, impl Register<5> for test). So I’m thinking why a generic placeholder has to be specified (as in test2). I guess it’s kind of like type parameter defaults, where it’s okay not to specify all the params? I just think that the syntax would be nicer if you didn’t need to specify the generic if it could be inferred (as I believe it is in test1)

[skreborn]

@ExplodingWaffle As far as I can tell; this is working as intended. You either omit all generics (including lifetimes, types, and constants), or you have to list them all, and this isn't specific to constants. You can still just place an underscore and let the compiler infer the type, but you do have to list them, as eliding just some of the generics is not allowed.

[clarfonthey]

I noticed that there aren't any open issues for this feature; are there any unmentioned blockers to stabilisation for this?

[JulianKnodt]

None that I'm aware of it, but in this issue it is noted that the implementation is brittle.

[clarfonthey]

Hmm, that definitely is an issue, but I feel like it shouldn't stop stabilisation here, since the simple case of const ARR: [T; _] = [/* ... */] still works fine, and I don't think this explicitly breaks anything.

[kallehed]

Yeah I think it would be great if this was added, as this functionality is really good for using arrays over vectors.

[rdrpenguin04]

Is there any reason this isn't stable yet? The issue mentioned earlier doesn't state why the implementation is "brittle", and the common case is still nice to have.

[JulianKnodt]

At this point, I guess there hasn't been any specific brittleness issues. If you're interested in submitting a PR for the docs and stabilization PR, feel free to do so.

[BoxyUwU]

there hasnt been any issues afaik but that doesnt mean the impl isnt less good than would be ideal. a stabilization PR made today will not be merged

[clarfonthey]

Wouldn't an FCP be the proper way to bring up those types of issues? I'm not sure what else there would be to do if we're blocked on "making sure the impl is good" if no problems have been brought up so far.

[JulianKnodt]

I think it would be a good idea to move this forward, as it appears there is a sizable number of people using it, and thus it would be good on stable. If an FCP is necessary, what steps would that would require, and would I need to be the one to create that?

[BoxyUwU]

again, a stabilization PR will not be merged. The current implementation of the feature is too prone to bugs. It is not a matter of "finding bugs in the current impl" its a matter of implementing the feature in such a way that we're not likely to introduce bugs as rustc evolves

[clarfonthey]

Right, I guess the main confusion is what's needed to do that. Like, is there some documentation somewhere that demonstrates these limitations, bugs filed as issues, etc. that we can point to or is this a task for someone more knowledgeable to work on whose attention is better put towards other things?

[BoxyUwU]

The current issue with the implementation is that there are too many ways of representing infer vars in the hir. We have TyKind::Infer, GenericArg::Infer, and ArrayLen::Infer. It would be too easy for someone to check only for a TyKind::Infer generic arg but forget about GenericArg::Infer, or check both of those but forget about ArrayLen::Infer.

At this moment I'm not entirely sure what the best way of fixing this is. rust-lang/compiler-team#480 was an attempt to fix this but it was too broad (attempted to also support unbraced const param arguments), did not solve ArrayLen::Infer, and I'm not even sure how nice removing TyKind::Infer would be since we use hir::Ty in places for things that arent generic args.

edit: filed an issue for this and put it under the steps for this tracking issue

[clarfonthey]

Thank you for looking into this, Boxy. This definitely doesn't seem like an easily fixed issue, although hopefully someone with better knowledge of HIR internals (or someone with a lot of time to learn) can eventually take a stab at this.

[mominul]

Can this feature be prioritized? It's an important addition to the usability of arrays when using it instead of vectors.

[clarfonthey]

The best way for showing support for this feature is mentioning it in the current state of Rust survey so it's on people's radar. Comments here don't really help, and if anything, they just ping people for not many good reasons.

We all really want the feature, but it seems like a fair bit of effort is left making it work properly, and it's mostly a discussion of whether that effort is best spent here or elsewhere.