Add TyKind::Const and remove GenericArgKind::Const

[oli-obk]

Proposal

Const generics are (modulo syntax-level features) essentially equivalent to types (as shown by the fact that typenum had implemented them since forever (1.0?)).

Pros:

• Treating them the same requires less duplication of logic, as it is "just" another variant of TyKind, which already needs to handle ty::Const within things like array types
• The order of constants coming after types in generic arguments is already being removed, this makes it truly irrelevant.
• It feels very neat from a type system perspective
• It may make chalk integration easier
• It can be implemented incrementally and switched over via a flag

Cons:

• Treating them differently makes it easier to prevent accidentally treating them the same where we shouldn't.
  • e.g. we could now represent trait bounds on constant values or have constants as the type of variables.
• we need to handle them in layout computation and other places where we have no concept for them.
• This may not work out as nicely as I imagine and may be a lot of wasted work

Curiosities:

• People may get motivated to push for features like impl Trait for 42 {} or let x: 42 ZST types

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

While there is a real issue here (duplication between types and consts for inference, placeholders, parameters, ...) I am unsure about the correct approach here, I'll create a new MCP if I can find a better way

[eddyb]

While there is a real issue here (duplication between types and consts for inference, placeholders, parameters, ...) I am unsure about the correct approach here, I'll create a new MCP if I can find a better way

Duplication is across all kinds (i.e. lifetimes too, and potentially HKT in the future), not just types vs consts.

This is the kind (hah) of usecase for calling GenericArg something more like Term: it could be not just literally Ty | &ty::Const | ty::Region but its own thing with the common parts of those factored out.

I think I would suggest doing this experiment in Chalk first, and coordinating with everyone who has a stake in typesystem design.