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

Simplify the with construct semantics #119

Open
LPTK opened this issue Jul 13, 2022 · 0 comments
Open

Simplify the with construct semantics #119

LPTK opened this issue Jul 13, 2022 · 0 comments
Labels

Comments

@LPTK
Copy link
Contributor

LPTK commented Jul 13, 2022

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.

@LPTK LPTK added enhancement New feature or request good intermediate issue labels Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 📋 Backlog
Development

No branches or pull requests

1 participant