New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support underscores as constant names #2526

Merged
merged 2 commits into from Oct 8, 2018

Conversation

@joshlf
Contributor

joshlf commented Aug 20, 2018

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

Rendered
Tracking issue

Discussion on internals here.

@Centril Centril added the T-lang label Aug 20, 2018

@ExpHP

This comment has been minimized.

Show comment
Hide comment
@ExpHP

ExpHP Aug 20, 2018

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.

ExpHP commented Aug 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@joshlf

joshlf Aug 21, 2018

Contributor

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?

Contributor

joshlf commented Aug 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Nemo157

Nemo157 Aug 21, 2018

Contributor

@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!.

Contributor

Nemo157 commented Aug 21, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@nox

nox Aug 21, 2018

Contributor

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.

Contributor

nox commented Aug 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mcarton

mcarton Aug 21, 2018

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

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

mcarton commented Aug 21, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Aug 21, 2018

Contributor

@mcarton see discussion on internals starting here

Contributor

Centril commented Aug 21, 2018

@mcarton see discussion on internals starting here

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 21, 2018

Member

This seems reasonable to me.

Member

joshtriplett commented Aug 21, 2018

This seems reasonable to me.

@upsuper

This comment has been minimized.

Show comment
Hide comment
@upsuper

upsuper Aug 22, 2018

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

upsuper commented Aug 22, 2018

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

@joshlf

This comment has been minimized.

Show comment
Hide comment
@joshlf

joshlf Aug 23, 2018

Contributor

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

Added to the Alternatives section.

Contributor

joshlf commented Aug 23, 2018

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

Added to the Alternatives section.

@Centril Centril self-assigned this Aug 30, 2018

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Aug 30, 2018

Contributor

@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.

Contributor

Centril commented Aug 30, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Aug 30, 2018

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

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.

rfcbot commented Aug 30, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@Havvy

Havvy Sep 26, 2018

Contributor

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.

Contributor

Havvy commented Sep 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Sep 26, 2018

Contributor

@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.

Contributor

Centril commented Sep 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@Havvy

Havvy Sep 26, 2018

Contributor

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.

Contributor

Havvy commented Sep 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Sep 26, 2018

Contributor

@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...).

Contributor

Centril commented Sep 26, 2018

@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 comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 27, 2018

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

rfcbot commented Sep 27, 2018

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

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Oct 4, 2018

Contributor

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.

Contributor

durka commented Oct 4, 2018

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.

Show outdated Hide outdated text/0000-const-wildcard.md Outdated
@joshlf

This comment has been minimized.

Show comment
Hide comment
@joshlf

joshlf Oct 4, 2018

Contributor

@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.

Contributor

joshlf commented Oct 4, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Oct 7, 2018

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

rfcbot commented Oct 7, 2018

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

@Centril Centril merged commit cbbc5a7 into rust-lang:master Oct 8, 2018

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Oct 8, 2018

Contributor

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#54912

Contributor

Centril commented Oct 8, 2018

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#54912

@matthiaskrgr

This comment has been minimized.

Show comment
Hide comment
@matthiaskrgr

matthiaskrgr Oct 8, 2018

The Rendered url 404s :(

matthiaskrgr commented Oct 8, 2018

The Rendered url 404s :(

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Oct 8, 2018

Contributor

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

Contributor

Centril commented Oct 8, 2018

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

@matthiaskrgr

This comment has been minimized.

Show comment
Hide comment
@matthiaskrgr

matthiaskrgr Oct 8, 2018

Ooh, sorry! 😆

matthiaskrgr commented Oct 8, 2018

Ooh, sorry! 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment