Skip to content

clarify Final reassignment semantics#2241

Open
KotlinIsland wants to merge 1 commit intopython:mainfrom
KotlinIsland:final-reassignment
Open

clarify Final reassignment semantics#2241
KotlinIsland wants to merge 1 commit intopython:mainfrom
KotlinIsland:final-reassignment

Conversation

@KotlinIsland
Copy link
Copy Markdown
Contributor

@KotlinIsland KotlinIsland commented Apr 7, 2026

Copy link
Copy Markdown
Member

@carljm carljm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a superior rule, but I would be likely to think so, since it's the rule ty already implements 😆

I think this PR needs some improvements, but I'm in favor of the change.

@KotlinIsland KotlinIsland force-pushed the final-reassignment branch 2 times, most recently from db50e16 to 790786b Compare April 7, 2026 11:53
@KotlinIsland KotlinIsland requested a review from carljm April 7, 2026 11:53
else:
ID3 = 2 # OK

ID4: Final[int] # E: not exhaustive assignment
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree that it should be required to enforce exhaustive assignment. Why should this be enforced for a Final name, but not for other names?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would expect a type checker to enforce this for all names. but this change is only regarding Final, which to me is even more "static" than normal variables, that a Final name without a value should always be impossible

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.

2 participants