Skip to content

Conversation

@mihaiboros
Copy link
Contributor

Fix #1342
Not a definitive fix, but it will reduce the chance of name clashes and shadowing.

@hsutter
Copy link
Owner

hsutter commented Mar 1, 2025

Thanks for pointing out this problem.

In general, this highlights a problem I hadn't noticed before between generated code and user code... the @enum metafunction generates a function that has a parameter named s, and so the style rule not to shadow a type scope name fired... which highlights that such style rules create a tension between generated code and user-written code.

I'll create a commit remove the style rule instead of taking this fix, so I'll close this PR, but thanks for highlighting the problem!

@hsutter hsutter closed this Mar 1, 2025
hsutter added a commit that referenced this pull request Mar 1, 2025
See #1373

The programmer can always write `this.` to disambiguate. This originally seemed like a useful constraint, but it creates a tension between generated code and user code. For example, see #1373, and the example

    foo : @enum type = { s; }

which before this commit was rejected because the `@enum` type metafunction generates a function with a parameter named `s`.

It seems undesirable to force generated code to uglify its names to avoid conflicts.

Also, fix `@enum` for cases like this to type-scope-qualify access to the member.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Enum member called 's' is not possible

2 participants