Skip to content

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

Closed
Closed
Allow declarations with names that collide with primitive types when using @"" syntax#6062
Assignees
andrewrk
Labels
acceptedThis proposal is planned.proposalThis issue suggests language modifications. If it also has the "accepted" label then it is planned.
Milestone
0.9.0

Description

@Vexu
Vexu
opened on 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

Activity

  1. Vexu
    added
    proposalThis issue suggests language modifications. If it also has the "accepted" label then it is planned.
    on Aug 15, 2020
  2. Vexu
    added this to the 0.8.0 milestone on Aug 15, 2020

  3. tadeokondrak commented on Sep 26, 2020

    @tadeokondrak
    tadeokondrak
    on Sep 26, 2020
    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.

  4. Vexu commented on Sep 26, 2020

    @Vexu
    Vexu
    on Sep 26, 2020
    MemberAuthor

    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.

  5. tadeokondrak commented on Sep 28, 2020

    @tadeokondrak
    tadeokondrak
    on Sep 28, 2020
    Contributor

    It would make sense for them to be distinct

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

  6. Vexu commented on Sep 30, 2020

    @Vexu
    Vexu
    on Sep 30, 2020
    MemberAuthor

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

  7. andrewrk
    modified the milestones: 0.8.0, 0.9.0 on May 19, 2021
  8. andrewrk
    added
    acceptedThis proposal is planned.
    on Aug 28, 2021
  9. andrewrk
    self-assigned this
    on Aug 28, 2021
  10. andrewrk
    closed this as completedin f30aa25on Aug 28, 2021

  11. andrewrk commented on Aug 28, 2021

    @andrewrk
    andrewrk
    on Aug 28, 2021
    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

Metadata

Metadata

Assignees

Labels

acceptedThis proposal is planned.proposalThis issue suggests language modifications. If it also has the "accepted" label then it is planned.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions