-
-
Notifications
You must be signed in to change notification settings - Fork 667
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
Enforce strict field initialization #1349
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks pretty good for me
Co-authored-by: Max Graey <maxgraey@gmail.com>
Co-authored-by: Max Graey <maxgraey@gmail.com>
🎉 This PR is included in version 0.13.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Looks like if a constructor has the Is that intentional? |
Sounds like a bug to me. Need to check. |
As a follow-up to #1155, this PR implements strict field initialization and makes it the default, so we always get the safety guarantees we need in AOT. I expect this to be somewhat controversial because it's stricter than TS in potentially unsafe scenarios.
To give a typical example:
must instead be written like
or using definite assignment syntax to automatically inject the assert:
essentially enforcing an actual safety check for the case where
Foo#bar
is being accessed too early inBar#constructor
.What this PR doesn't do compared to TS, however, is to enforce strict initialization of fields that can be trivially initialized with zero (which is our
undefined
), like of typei32
,f64
or a nullable type likestring | null
, so one can leave these uninitialized instead of adding boilerplate assignments, similar to locals or globals.For more examples of what's allowed and what's not, see:
fixes #1155