Tracking issue for RFC 2526, "Support underscores as constant names"

[Centril]

This is a tracking issue for the RFC "Support underscores as constant names" (rust-lang/rfcs#2526).

Steps:

• Implement the RFC – Support underscore as constant name #55015
• Implement static _ as well
• Adjust documentation (see instructions on forge)
  • Document underscore_const_names reference#620
• Stabilization PR (see instructions on forge)
  • Stabilize underscore_const_names in 1.37.0 #61347

Unresolved questions:

None

[petrochenkov]

Ugh, seems like a legitimized hack rather than a... well, any of several proper features to which this can be generalized.

At least this is a very tiny hack.
Implementation strategy is the same as for use Trait as _;.
If we encounter _ instead of the const name identifier, then we create a gensym for it instead of storing it in AST directly (so that different _s do not conflict).
Together with a feature gate and tests that would be all the implementation.

[Centril]

Ugh, seems like a legitimized hack rather than a... well, any of several proper features to which this can be generalized.

Hehe, I agree we should generalize (to patterns) eventually but it seemed that it was much more complex from @eddyb's comments. :)

[dsciarra]

looks interesting, I will give it a try!

[earthengine]

@petrochenkov

Can we also ensure that those gensyms get removed after before codegen? This means, the generated MIR should be removed in some MIR rounds.

[oli-obk]

We don't need to remove any MIR. Unused private constants don't end up in metadata.

[earthengine]

@oli-obk

Fine. There is one "inconsistency" in Rust today:

let _: str = *"123"; //Legal
let _v: str = *"123"; //Illegal unless unsized_rvalues

When implementing this, how do we want to justify

const _: str = *"123";
const _v: str = *"123";

Shall we repeat the inconsistency, or shall we count both valid or invalid?

[oli-obk]

I'd start out with both being disallowed, since that is the current behaviour of constants. But I have no strong opinion.

[Centril]

Setting earliest date for stabilization proposal to 25th november 2018 (14 days from now).

We'll likely want to discuss what direction generalizations should go in before stabilizing.

[oli-obk]

The RFC did not discuss static _: T = ...;. Is that supposed to work, too? (the implementation does in fact allow this, accidentally even without a feature gate)

Fix for the stability hole is in #55983

[nikomatsakis]

I'm having a bit of second thoughts about this RFC. I feel like (a) the intention of const _: T = { .. } is pretty unclear and (b) it opens some weird questions about e.g. generic constants and how they fit here and (c) it doesn't support full patterns, which it kind of suggests it would support.

The motivation of "ensure some code type-checks" is real though. I sort of like the syntax const { ... } for that purpose. Thoughts?

I guess I'm probably just re-raising thoughts that came up on the RFC.

[RalfJung]

I sort of like the syntax const { ... } for that purpose. Thoughts?

Could that be re-used for explicit promotion as @oli-obk plans it?

[nikomatsakis]

@RalfJung seems plausible. The one concern I could see is whether there would be some conflict as const { .. } could be an item and an expression, and we might want the latter to inherit the lexical scope from the surrounding fn, so it can refer to generic constant names -- but we could just say that const { .. } items cannot appear in functions (since...what's the point).

[cramertj]

but we could just say that const { .. } items cannot appear in functions (since...what's the point).

Wouldn't that defeat the purpose of explicit promotion?

[Centril]

With respect to a) the intention of const _: T = { ... }; being unclear I agree with that in isolation. However, in the context of being wrapped in a macro such as const_assert! { ... } or inside a derive macro it feels rather clear what the purpose of this construct is.

My main worry is instead b) and c). That is, would we permit this?

const (A, B): (AType, BType) = (1, 2);

(this would be the natural extension of const _: Type = expr; because _ acts as a pattern in this context.

but also this?

const A<T>: AType<T> = expr;

and how can these be composed?

If we write:

const (A<T>, B<U>): (AType<U>, BType<T>) = expr;

does that make any sense?

I suppose that we could support generic constants when A<T> is written and patterns otherwise; that likely works syntactically but it could cause confusion (or maybe not... I'm not sure).

Finally, ideally, to keep the language consistent, we should keep const and static items as much as possible in sync syntactically. If we support const _: Type = expr; we should imo support static _: Type = expr; even if we lint on the latter.

---

As for supporting const { ... }, I think the meaning here isn't clear... there could be 2 different interpretations:

1. The entire block { ... } is evaluated at compile time. This interpretation is based on const items.
2. The entire block may be evaluated at compile time if all variables referenced are. Notably, you could write: let x = random(); let y = const { x * x };. This interpretation is based on const fn items. 2. would subsume 1.

[RalfJung]

Wouldn't that defeat the purpose of explicit promotion?

const expressions would be allowed in function bodies, just const items would not.

[DoumanAsh]

I feel like (a) the intention of const _: T = { .. } is pretty unclear

I believe it is pretty clear to user as we can use let VAR = { ... }

[oli-obk]

The entire block may be evaluated at compile time if all variables referenced are. Notably, you could write: let x = random(); let y = const { x * x };. This interpretation is based on const fn items. 2. would subsume 1.

I don't think that's a useful interpretation. There's absolutely nothing this const block could promise us. It's just regular code.

I agree with everything else. We should just allow constants with patterns and generic constants. We already support them inconveniently by defining a const function without arguments.

[Centril]

It's just regular code.

It's not. Notably, you may only reference existing bindings. Any function calls must still be const fn. For example, let y = const { random() }; would not be allowed.

I don't think that's a useful interpretation. There's absolutely nothing this const block could promise us.

There's plenty this would tell you:

1. If you reference no bindings from outside you know it is evaluated at compile time.
2. The block does not admit non-determinism even if bindings referenced are non-deterministically evaluated. This gives you a local way to enforce freedom from certain side-effects.

Now.. it might be confusing to have block form entitled const { .. } behave in this way, but that doesn't mean it isn't useful to behave in this way.

[nox]

I don't really understand how generic constants can cause issues with unnamed consts, and AFAIK supporting _ is fully forwards-compatible with generalising const to fully accept patterns. Is there any chance this could be stabilised? Many derive macros out there currently generate a difficult-to-guess const name to scope extern crate and use statements.

[roblabla]

Currently, the constants show up as _ in the documentation. https://sunriseos.github.io/SunriseOS/master/sunrise_ahci/hba/index.html#constants

[withoutboats]

I think we should stabilize this as soon as its implemented; I'd expect statics and consts to both be irrefutable pattern positions. I don't think its important to keep statics and consts the same; I think its already inconsistent that they don't take irrefutable patterns, and bringing one of them closer to that now is better than waiting until they are both at feature parity and moving them together. In particular, unnamed statics have real semantic questions as to whether the place gets created or not.

[petrochenkov]

If the _ is interpreted as a pattern, and not as a unique identifier like in use foo as _;, then the implementation needs to be changed to not add the names of _ consts into their parent modules.

[RalfJung]

let _ = is a weird beast, so the following sticks out from the RFC:

Just like let _, this doesn't introduce any new bindings, but still evaluates the rvalue at compile time like any other constant.

That's not "just like let _". let _ evaluates the place but never performs the place-to-rvalue coercion. Specifically, let _ = *v does not access memory, and let _ = mutex.lock().unwrap() does not drop the guard.

[earthengine]

It is unfortunate that Rust was designed that way and we do not have a way back. It is really confusing to even experienced users unless they jump into the very deep level of the language.

If this feature could ever be designed again, I would hope that let _ = ... to always performs the place-to-rvalue coercion unless it is no-op, so we have less weirdness.

That's not "just like let _". let _ evaluates the place but never performs the place-to-rvalue coercion. Specifically, let _ = *v does not access memory, and let _ = mutex.lock().unwrap() does not drop the guard.

[nox]

Specifically, let _ = *v does not access memory, and let _ = mutex.lock().unwrap() does not drop the guard.

Did you mean that it does drop the guard?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=94047cd4bd5f9e822ad19bdd55c15291

[RalfJung]

Dang, it got me again... this does not drop though:

fn main() {
    let mutex = Mutex::new(());
    let val = mutex.lock().unwrap();
    let _ = val; // does not drop nor move.
    let _ = mutex.lock().unwrap();
}

[eddyb]

That's not "just like let _". let _ evaluates the place but never performs the place-to-rvalue coercion. Specifically, let _ = *v does not access memory, and let _ = mutex.lock().unwrap() does not drop the guard.

I think the confusion here is the direction of the conversion. Matching against a pattern always does a "value to place" conversion, as patterns require places to do discriminant checks and field accesses, so:

• let _ = place_expr; evaluates but doesn't access the place, so it's close to &raw place_expr
• let _ = value_expr; evaluates the value, puts it in a temporary place, which gets dropped, so identical in behavior to drop(value_expr);, value_expr; or many other uses of a value expression where the value gets dropped - including &raw place_expr;!

So depending on some exact details around unsafe code and whatnot, let _ = e; might be equivalent to &raw e; in all cases (ignoring optimizations, or assuming unused address-of are ignored).

[Centril]

If the _ is interpreted as a pattern, and not as a unique identifier like in use foo as _;, then the implementation needs to be changed to not add the names of _ consts into their parent modules.

I think it would be good to fix this so that we treat const _: T = expr; as we do with extern { .. } and foo!(); in an item position right now. That is, it doesn't have a name, and we don't gensym. That might perhaps involve having Option<Ident> in the hir::Item.

[eddyb]

You don't need Option because extern {...} and foo!(); already work with ident: Ident in {ast,hir}::Item (via the "Invalid" "keyword", aka Symbol::intern("")).

[Centril]

@petrochenkov Are there any observable differences between _ as PatKind::Wild and using gensyms as it is implemented right now (aside from rustdoc which isn't important here) such that it matters wrt. stability and forward compatibility?

[petrochenkov]

Are there any observable differences between _ as PatKind::Wild and using gensyms as it is implemented right now

No, there should be no observable difference after #56392.
They just create some extra work for the resolver and also encoder/decoder, I think.

[Centril]

We discussed this on the language team meeting today and gave the green light for a stabilization report and PR (see above). I will be writing the report and adding it to the PR within a few hours.