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

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
9 participants
@joshlf

joshlf commented Aug 20, 2018

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

Rendered

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

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?

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

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

Added to the Alternatives section.

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.

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