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

Color Color interaction with disallowed access to struct this in local function #932

Closed
KalleOlaviNiemitalo opened this issue Sep 14, 2023 · 2 comments
Assignees
Labels
resolved: by-design The issue was examined, and we decided it wasn't a problem after all

Comments

@KalleOlaviNiemitalo
Copy link
Contributor

KalleOlaviNiemitalo commented Sep 14, 2023

Describe the bug

In C# 7, §13.6.4 (Local function declarations) disallows access to this in a local function when the type of this is a struct type. That rule was added to fix #926. It should be verified whether the rule interacts with the Color Color scenario in §12.8.7.2 (Identical simple names and type names).

When the type of this is a struct type, it is a compile-time error for the body of a local function to access this. This is true whether the access is explicit (as in this.x) or implicit (as in x where x is an instance member of the struct). This rule only prohibits such access and does not affect whether member lookup results in a member of the struct.

Example

The following should be allowed, even though the name lookup of Color in Color.Black finds the instance field Color Color and that might be understood as a disallowed access to an instance field of this.

enum Color {
    Black
}
struct S {
    Color Color;
    void M() {
        Color L() => Color.Black;
    }
}

Expected behavior

Not sure if anything needs to be changed. Perhaps the wording already allows the above.

Additional context

Inspired by #832 and #931 but does not involve nameof.

@jskeet jskeet self-assigned this Sep 14, 2023
@jskeet
Copy link
Contributor

jskeet commented Sep 14, 2023

Will have a look - I suspect this will be a case of:

  • If it's already fine, that's great
  • If it looks like an easy fix, we can get it done in C# 7
  • If it looks really fiddly (or a small fix that we're unsure of) we may punt to after C# 7

@jskeet
Copy link
Contributor

jskeet commented Sep 14, 2023

I believe this is already covered by 12.8.7.2:

In a member access of the form E.I, if E is a single identifier, and if the meaning of E as a simple_name (§12.8.4) is a constant, field, property, local variable, or parameter with the same type as the meaning of E as a type_name (§7.8.1), then both possible meanings of E are permitted.

The example translates directly to the struct case - Color.Black is fine; Color.Complement() is prohibited.

Closing as not needing any other work - but please shout if you think I've missed something.

@jskeet jskeet closed this as completed Sep 14, 2023
@jskeet jskeet added the resolved: by-design The issue was examined, and we decided it wasn't a problem after all label Sep 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolved: by-design The issue was examined, and we decided it wasn't a problem after all
Projects
None yet
Development

No branches or pull requests

2 participants