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
Currently, this construct can override fields from classes with incompatible types while keeping the class identity (nominal tag). This is sound because the bare identity only informs about runtime instance testing and not about any specific field types – for that, one needs the full class type.
The flip side of the coin is that we cannot assume anythings from bare class identity although we'd often like to. This makes the types inferred from pattern matching very precise but also weird looking/alien, and it means the type simplifier has to work a lot harder when trying to reconstruct good looking full class types. It also pushes us to represent the field sets of type normal forms extensively rather than intensively, making handling them inefficient. Also, the concept of bare nominal tags doesn't have an equivalent in TS, making inferring them so easily extra awkward for interop.
It would be much nicer to make with strip class identity (both statically and dynamically), so that we can assume that class nominal tags imply the corresponding fields. So with will only ever create plain records. This is incidentally already what it does with tuples.
A different construct could be used to extend class values while getting a class instance as a result instead of a plain record. Something like new Foo {...foo; x = v} instead of the current foo with {x = v}. Making the target class Foo explicit solves the issue by curbing the feature's expressiveness and dynamicity.
The text was updated successfully, but these errors were encountered:
Currently, this construct can override fields from classes with incompatible types while keeping the class identity (nominal tag). This is sound because the bare identity only informs about runtime instance testing and not about any specific field types – for that, one needs the full class type.
The flip side of the coin is that we cannot assume anythings from bare class identity although we'd often like to. This makes the types inferred from pattern matching very precise but also weird looking/alien, and it means the type simplifier has to work a lot harder when trying to reconstruct good looking full class types. It also pushes us to represent the field sets of type normal forms extensively rather than intensively, making handling them inefficient. Also, the concept of bare nominal tags doesn't have an equivalent in TS, making inferring them so easily extra awkward for interop.
It would be much nicer to make
with
strip class identity (both statically and dynamically), so that we can assume that class nominal tags imply the corresponding fields. Sowith
will only ever create plain records. This is incidentally already what it does with tuples.A different construct could be used to extend class values while getting a class instance as a result instead of a plain record. Something like
new Foo {...foo; x = v}
instead of the currentfoo with {x = v}
. Making the target classFoo
explicit solves the issue by curbing the feature's expressiveness and dynamicity.The text was updated successfully, but these errors were encountered: