Stabilize underscore_const_names in 1.37.0

[Centril]

You are now permitted to write:

const _: $type_expression = $term_expression;

That is, we change the grammar of items, as written in the .lyg notation, from:

Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IDENT ":" ty:Type "=" value:Expr ";" }
  | ...
  ;

into:

Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IdentOrUnderscore ":" ty:Type "=" value:Expr ";" }
  | ...
  ;

IdentOrUnderscore =
  | Named:IDENT
  | NoName:"_"
  ;

r? @petrochenkov

[Centril]

Stabilization proposal

I propose that we stabilize #![feature(underscore_const_names)].

@rfcbot merge

Tracking issue: #54912
Version target: 1.37 (2019-07-04 => beta, 2019-08-15 => stable).

What is stabilized

You are now permitted to write:

const _: $type_expression = $term_expression;

That is, we change the grammar of items, as written in the .lyg notation, from:

Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IDENT ":" ty:Type "=" value:Expr ";" }
  | ...
  ;

into:

Item = attrs:OuterAttr* vis:Vis? kind:ItemKind;
ItemKind =
  | ...
  | Const:{ "const" name:IdentOrUnderscore ":" ty:Type "=" value:Expr ";" }
  | ...
  ;

IdentOrUnderscore =
  | Named:IDENT
  | NoName:"_"
  ;

When name = NoName occurs then there are no run-time semantics because an unnamed constant cannot be referred to. With respect to compile-time dynamic semantics, the same rules apply as an unused constant has today. E.g., if you have const _: () = <diverges>; then #[deny(const_err)] will trigger. As for static semantics, an unnamed constant item behaves as normal with respect to type checking.

What is not stabilized

• Only a free const item may use _ as its name. Associated ones may not.
• Non-const items may not use _ as a name. Notably, static items may not.
• const items may not use arbitrary irrefutable patterns. E.g., we do not permit const (A, B): (u8, u8) = (1, 2);

Divergences from RFC and unresolved questions

None.

Tests

The tests can be primarily seen in the PR itself. Here are some of them:

• Feature gate test being removed

• const _: $ty = $expr compiles, permits types other than (), permits duplicates including when used with macros

• Only free const items permit _ as a name

History

• In Implement import renaming with _ (RFC 2166) #48922 import renaming with _ was implemented.
  The PR was written by @petrochenkov, reviewed by @nikomatsakis, and was merged on 2018-03-16.
  The PR added the now stabilized underscore_imports feature under which you may write e.g.

  extern crate foo as _;
  use bar as _;

• RFC 2526 by @joshlf then proposed to add const _: $type = $expr; and was merged on 2018-10-08 after which the tracking issue Tracking issue for RFC 2526, "Support underscores as constant names" #54912 was filed.

• The underscore_const_names feature was then implemented in Support underscore as constant name #55015 on 2018-10-14 by @dsciarra. The PR was reviewed by @petrochenkov.

• In Tracking issue for RFC 2526, "Support underscores as constant names" #54912 (comment), @oli-obk found a stability hole which allowed static _: $type = $expr;. @oli-obk plugged this stability hole in Fix stability hole with static _ #55983 which was then subsequently beta-backported. This PR, merged on 2019-11-20 was reviewed by @nikomatsakis.

• In Delay gensym creation for "underscore items" (use foo as _/const _) until name resolution #56392, @petrochenkov adjusted underscore_imports and underscore_const_names such that gensym creation happens first after name resolution. Moreover, the PR, merged on 2018-12-06 and reviewed by @oli-obk, prohibited accidentally implemented static _: $type = $expr.

• This PR stabilizes underscore_const_names and hardens the tests in some respects.

Motivation

The general motivation for const _: $type = $expr; is to facilitate writing well-behaved macros.
For example, procedural macros such as serde_derive generate a constant item to wrap the implementation into. Another example of this is proptest_derive which generates roughly:

#[allow(non_upper_case_globals)]
const _IMPL_ARBITRARY_FOR_MyType: () = {
    impl proptest::arbitrary::Arbitrary for MyType {
        ...
    }
};

Instead, it would be better to generate:

const _: () = {
    impl proptest::arbitrary::Arbitrary for MyType {
        ...
    }
};

This not only has the advantage of generating less code, but also produces better diagnostics.

Other motivational examples include:

• Tracking issue for RFC 2526, "Support underscores as constant names" #54912 (comment)

• The name __initXXXXXXX is defined multiple times dtolnay/inventory#8 which, as far as we know, cannot be fixed otherwise.

• Static assertions as discussed in Limitations nvzqz/static-assertions#1 (comment). Such static assertions are also used within the compiler as seen in https://github.com/rust-lang/rust/blob/63829d2dcfd3e61a9e48cf33aead8faad8079e8a/src/librustc_data_structures/macros.rs.

More generally, const _: () = $expr; is an idiom allowing users to type check a piece of code but not necessarily more than that.

Potential concerns

There is some concern that underscore_const_names is an ad-hoc way to achieve the desired outcomes. In particular, instead of supporting identifiers or an underscore, we could support arbitrary irrefutable patterns for const items. Moreover, stabilizing const _ would further diverge constant items from static items which could ostensibly also support underscores or even arbitrary irrefutable patterns. However, there are open semantic questions with static _ and arbitrary irrefutable patterns for const requires more work in the compiler. In any case, the stabilization of const _ still keeps us forward compatible with such extensions and therefore these concerns may be put aside for the time being.

There is also some concern of how const _ would compose with associated constants as well as generic ones. Presumably, something like const (A, _)<T>... does not make sense but we also do not have to support the combination of arbitrary irrefutable patterns and generic constants. As for associated constants, one could imagine defining or providing multiple associated constants through pattern matching one constant expression inside an implementation. All in all, the generalization problems do not seem insurmountable.

Some considered alternatives

Unnamed modules, mod _ { ... }

As an alternative to const _: $type = $expr; one could allow mod _ { ... } instead.
The grammar for mod items would use the same IdentOrUnderscore production. When considering mod _ { ... } note that:

• It is often the point of const _: $type = $expr; to check that an $expression satisfies some condition, e.g., that it is an expression that does not diverge (const_assert!(...)). In these cases, mod _ { ... } is at a disadvantage because the body accepts items and not expressions. To remedy this, you'd need a const item inside the mod item thus unnecessarily generating more tokens. Meanwhile, fitting an item inside an expr requires less.

• mod _ { ... } has the same problems wrt. generics as const _: $type = $expr; has. Namely, one could consider generic modules mod _<T, ...> { ... }. However, there's no strange interactions between pattern matching and generics here.

• mod _ { ... } has fewer interactions and is less generalizable. This can both be a good thing because it is more "complete" sooner but it can also feel more ad-hoc. However, we already have use foo as _; so the production IndentOrUnderscore already exists in stable Rust.

Overall, we believe const _ to be a better fit because it has a natural generalization and works better with macros overall.

const { ... } blocks

Another alternative would be some sort of const { ... } block. This would take the grammatical form:

ItemKind =
  | ...
  | ConstBlock:{ "const" value:Block }
  | ...
  ;

ExprKind =
  | ...
  | ConstBlock:{ "const" value:Block }
  | ...
  ;

Notably, const { ... } would have the double duty as an expression and item form.
Assigning unsurprising semantics to const { ... } as an expression is easy: the block is a const context and as any block it may contain a series of statements followed by an optional tail expression which is the value of the block. As an item, it is less clear what the tail expression would be. Would we require that the tail expression be implicitly coercible to ()? Would we allow a tail expression at all? Overall, a const { ... } is probably a better fit solely as an expression form and not as an item.

Possible future work

As aforementioned, natural extensions to const _: $type = $expr; primarily includes:

• Extending _ to $pat.
• Extending _ or $pat to static items as well. In this case we should figure out what consistent, useful, and expected dynamic semantics are for situations such as static (A, _): (u8, u8) = (1, 2);.
• Finally, we should consider whether it would make sense to extend const _ to associated constants as well and what implications this has for static items.

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Centril]

N.B. Aaron is on leave so I've checked his box.

[petrochenkov]

Implementation LGMT, marking as waiting on team.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[brson]

Looks like quite a hack to achieve the stated outcome. Reminds me of javascript.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[Centril]

@bors r=petrochenkov

[bors]

📌 Commit e62c9d7 has been approved by petrochenkov

[bors]

⌛ Testing commit e62c9d7 with merge 4edff84...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrochenkov
Pushing 4edff84 to master...

[nvzqz]

Thanks @Centril for putting in the work in getting this feature stabilized. With it, I should be able to release 1.0 of static_assertions with the release of 1.37.0 this Thursday! 🎉

[Centril]

@nvzqz Happy to see this already having a nice impact! :)

Maybe we can start using static_assertions in the compiler as well? -- cc @Zoxc

[eddyb]

I think we have our own hacky version in rustc_data_structures?
Besides, const _: () = assert!(...); is the static_assert! we want 😉

[Centril]

Yep, we have one here: https://github.com/rust-lang/rust/blob/master/src/librustc_data_structures/macros.rs

[nvzqz]

The crate offers functionality outside of const_assert! that the compiler could also leverage. Not sure where exactly since I'm not sufficiently familiar with its internals.

@eddyb I hope to make const_assert! wrap around assert! like that someday. It would produce significantly better error messages.