Support underscores as constant names

[joshlf]

Allow the syntax const _: TYPE = VALUE, analogous to let _ = VALUE.

Rendered
Tracking issue

Discussion on internals here.

[ExpHP]

Alternatives section looks barren. I know some ink has been spilt in the past on the alternative of unnamed modules (mod { ... } or mod _ { ... }), which appears to be equivalent in power.

IIRC, one of the primary arguments against that was that hygienic macro will solve the same problem; and that argument applies to this RFC too.

[joshlf]

Alternatives section looks barren. I know some ink has been spilt in the past on the alternative of unnamed modules (mod { ... } or mod _ { ... }), which appears to be equivalent in power.

Good call; I'll add that. Do you know where said ink was spilled so I can link to it?

IIRC, one of the primary arguments against that was that hygienic macro will solve the same problem; and that argument applies to this RFC too.

How would that work?

[Nemo157]

@joshlf decl_macros create hygienic items, so even if you use a macro generating a named const multiple times in the same scope those consts won't conflict, see this playground for a working assert_impl!.

[nox]

Declarative macros are unstable and way bigger than this proposal. That also forces you to use a macro when you could just be doing some compile-time assertions by hand or through a macro_rules macro.

I'm in favour of this proposal.

[mcarton]

How about supporting all irrefutable patterns in a similar way to let?

const (foo, bar): (T, U) = computeFooAndBar();

[Centril]

@mcarton see discussion on internals starting here

[joshtriplett]

This seems reasonable to me.

[upsuper]

Another alternative is to support unnamed fn like fn _() { ... } which should provide the same ability.

[joshlf]

Another alternative is to support unnamed fn like fn _() { ... } which should provide the same ability.

Added to the Alternatives section.

[Centril]

@rfcbot merge

We discussed the RFC on this week's language team meeting. The general consensus was that we should do this. The proposal seems small in scope, is readily implementable, and it would be useful in some cases (e.g. those mentioned in the motivation, particularly wrt. custom derive macros). It also seems to me that the meaning would be understandable given that let _ = ..; also works.

I would personally like us to go further in the future to generally allow irrefutable patterns so that you can write const (FOO, BAR) = EXPR; so that we align const even more with let, but this is a good first step.

[rfcbot]

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

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

No concerns currently listed.

Once a majority of reviewers approve (and none object), 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.

[Havvy]

Is there a reason to only allow this for const and not every item type? It feels inconsistent that consts can have them but e.g. structs can not.

[Centril]

@Havvy How would it work for struct and friends? E.g. if we would expand _ to patterns, would it make sense for structs?

I think consts should be primarily consistent with let bindings as much as we can muster to give consts an aura of being bindings. This is why I want to move towards accepting const $pat = $expr; in the future.

[Havvy]

No, it wouldn't make sense for any item other than const and static to take patterns. Although with static, design decisions have to be made on what it means.

But looking at _ in isolation, struct _ { t: () } would work, even if it's not a pattern. Though that would still be a different usage of _ than either pattern catch-all and type inference. So just allowing patterns on const seems like an okay-to-do-now thing.

[Centril]

@Havvy Right, in the case of struct _ { t: () } the _ is an identifier. I don't see any use cases for this or for enum _ { .. } other than possibly for one-of types (but then you also have to bake in construction, at which point structural records are cleaner...).

[rfcbot]

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

[durka]

If the only purpose of this is to create an anonymous top-level scope, it kind of seems like a hack.[1] Especially since you have to give the underscore a "type" of () and be sure to return () (you could instead give it a real type and use the return to do a typecheck, like const _: i32 = { hope_this_returns_int() }; but that doesn't work if your types are defined within the const).

If the goal is to have a facility for scopes at the top level, perhaps we should... just allow curly-braced scopes at top level?

---

[1] If consts could be declared with patterns, this could also be useful in the following code:

const fn foo() -> (i32, i32) { /* ... */ }
const (X, _): (i32, i32) = foo();

But that doesn't work today even with identifiers.

[durka]

A guide-level explanation does not include the word "rvalue", IMO. And this doesn't explain what the point of the feature is.

[joshlf]

Is there a phrase you'd suggest instead of "rvalue"?

The point of the feature is described in the "Motivation" section.

[Havvy]

What C and C++ call an rvalue, we call a value expression. See the reference on this.

[Centril]

I think we've called it rvalue for some time as well.. see https://github.com/rust-lang/rfcs/blob/master/text/1414-rvalue_static_promotion.md.

[rkruppe]

We used to call it rvalue, but we've wisened up since then. Likewise with lvalues (now places).

[Centril]

@rkruppe you speak the truth :)

[joshlf]

@durka As you suggest, the idea is that this is the first step on the way towards fully-general patterns like const (X, _): (i32, i32) = foo();. This isn't intended as the final stop.

[rfcbot]

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

[Centril]

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#54912

[matthiaskrgr]

The Rendered url 404s :(

[Centril]

@matthiaskrgr you know it takes a few seconds to change the URL and everything; I'm not a bot =P

[matthiaskrgr]

Ooh, sorry! 😆