Skip to content
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

Allow declarations with names that collide with primitive types when using @"" syntax #6062

Closed
Vexu opened this issue Aug 15, 2020 · 5 comments
Assignees
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@Vexu
Copy link
Member

Vexu commented Aug 15, 2020

Originally from here: #6060 (comment)
Alternative to #1802

const _ = 2; // error: `_` is not a declarable symbol
const @"_" = 2; // ok

const bool = 2; // error: variable shadows primitive type 'bool'
const @"bool" = 2; // ok
@Vexu Vexu added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Aug 15, 2020
@Vexu Vexu added this to the 0.8.0 milestone Aug 15, 2020
@tadeokondrak
Copy link
Contributor

Would this work?

const @"bool" = 2;
const other: bool = false;

If not, shadowing a predefined type or identifier would make it impossible to use, since you couldn't even do

const my_bool = bool;
const @"bool" = 2;
const other: my_bool = false;

since top level decls are order-independent.

@Vexu
Copy link
Member Author

Vexu commented Sep 26, 2020

It would make sense for them to be distinct since bool is a constant and allowing it to be modified by an alias would result in some really strange behavior.

@tadeokondrak
Copy link
Contributor

It would make sense for them to be distinct

Wouldn't the only way to implement that be the same as #1802?

@Vexu
Copy link
Member Author

Vexu commented Sep 30, 2020

No. This works because the identifiers using the @"" syntax are actually strings that need to be resolved first. The main difference between the two approaches is that this doesn't make them into keywords. This will be most noticeable in container fields where using bool will remain valid while the other proposal would require using @"bool".

@andrewrk
Copy link
Member

cc @ehaas - I believe some things you were doing were blocking on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants