You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should you be allowed to do this to a struct? This violates the "fixed layout" goal, under common implementations of private fields.
If no, how exactly is it denied?
Is the failure when you try to instantiate a class with a private field and its super constructor returns a struct? That's one option; that's how it works for WindowProxy.
Another option is to say that classes are forbidden from extending structs: i.e., it is an error if super() returns a struct (either because of class extends Struct or because of a return override). As a consequence you mechanically would not be able add a private field to a struct. I like this option.
Capturing a topic discussed in plenary and on Matrix.
The accursed return override trick lets you put private fields on (almost) any object, even a frozen object:
Should you be allowed to do this to a struct? This violates the "fixed layout" goal, under common implementations of private fields.
If no, how exactly is it denied?
Is the failure when you try to instantiate a class with a private field and its super constructor returns a struct? That's one option; that's how it works for WindowProxy.
Another option is to say that classes are forbidden from extending structs: i.e., it is an error if
super()
returns a struct (either because ofclass extends Struct
or because of a return override). As a consequence you mechanically would not be able add a private field to a struct. I like this option.cc @erights
The text was updated successfully, but these errors were encountered: