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

Always disallow assignments to constants #57567

Merged
merged 1 commit into from
Feb 28, 2025
Merged

Always disallow assignments to constants #57567

merged 1 commit into from
Feb 28, 2025

Conversation

Keno
Copy link
Member

@Keno Keno commented Feb 28, 2025

We have historically allowed the following without warning or error:

const x = 1
x = 1

As well as

const x = 1
x = 2

with a UB warning.

In 1.12, we made the second case error, as part of the general binding partition changes, but did not touch the first case, because it did not have the warning.

I think this made a reasonable amount of sense, because we essentially treated constants as special kinds of mutable globals (to which assignment happened to be UB).

However, in the 1.12+ design, constants and globals are quite sepearate beasts, and I think it makes sense to extend the error to the egal case also, even if it is technically more breaking.

In fact, I already thought that's what I did when I implemented the new effect model for global assignment, causing #57566. I can't think of a legitimate reason to keep this special case. For those who want to do binding replacement, the const keyword is mandatory, so the assignment is now literally always a semantic no-op or an error.

Fixes #57566.

@Keno
Copy link
Member Author

Keno commented Feb 28, 2025

(obviously

const x = 1
const x = 2

)
will continue to work (and also works on older versions with the usual UB caveat).

We have historically allowed the following without warning or error:

```
const x = 1
x = 1
```

As well as
```
const x = 1
x = 2
```
with a UB warning.

In 1.12, we made the second case error, as part of the general binding
partition changes, but did not touch the first case, because it did not
have the warning.

I think this made a reasonable amount of sense, because we essentially
treated constants as special kinds of mutable globals (to which assignment
happened to be UB).

However, in the 1.12+ design, constants and globals are quite sepearate
beasts, and I think it makes sense to extend the error to the egal case
also, even if it is technically more breaking.

In fact, I already thought that's what I did when I implemented the new
effect model for global assignment, causing #57566. I can't think of a
legitimate reason to keep this special case. For those who want to do
binding replacement, the `const` keyword is mandatory, so the assignment
is now literally always a semantic no-op or an error.

Fixes #57566.
@Keno Keno added the backport 1.12 Change should be backported to release-1.12 label Feb 28, 2025
@Keno
Copy link
Member Author

Keno commented Feb 28, 2025

Having heard no complaints in informal survey and since it currently segfaults, I'm just gonna go ahead and merge it. Happy to still entertain arguments in favor of the previous 1.12 behavior if anybody has them.

@Keno Keno merged commit 8f00a51 into master Feb 28, 2025
8 checks passed
@Keno Keno deleted the kf/57566 branch February 28, 2025 07:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.12 Change should be backported to release-1.12
Projects
None yet
Development

Successfully merging this pull request may close these issues.

const redefinition crashes with illegal hardware instruction
1 participant