TypeScript/AtScript union - what's going to happen to type system? structural always?

[giancarloa]

Hi there... this question is in regards to the recent TypeScript/AtScript news... if I understand things correctly, which I certainly may not, a lot of the AtScript features are now going to be implemented by TypeScript, particularly the features around metadata programming... however one AtScript feature that I have not been able to find more info on on the TypeScript side of things is the following (this comes from the old AtScript docs (https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit97HnZoKVygDxpWzEYW0U/edit):

Semantics Agnostic: Type system theory is a complex field with many tradeoffs. It is our explicit goal to leave the semantic discussion as well as the assertion system outside of the scope of AtScript. Instead we want to provide hooks for others to build runtime type assertion libraries and static analyzer tools with their own semantics. In this way we believe that we can spur innovation in the area of type systems by lowering the barrier to entry.

My question is will the above ever possibly be considered for TypeScript? Or is this simply just crazy talk for TypeScript?

To me personally this is the ONLY thing I really ever thought AtScript had an advantage of over TypeScript, just because a lot of the AtScript features, particularly around metadataprogramming, I think would have eventually made their way into TypeScript. But the above AtScript feature I thought was REALLY cool because, if I understand the feature correctly (which I may not), it would have allowed clients/tools to have more control of the type system enforced by the compiler. So for example in my case I generally prefer a nominal type system, like C#, over a structural type system like TypeScript. And man would it be cool that with the flip of a switch TypeScript would allow such a thing. I mean TypeScript could by default enforce a structural type system like today but it could potentially ship and enforce others, particularly a nominal type system.

[danquirk]

Yeah this isn't going to happen in the sense you're imagining. Having a pluggable type system sounds nice in theory (and there is some fun research in that space) but I'm not aware of any languages that have successfully used it with significant adoption. Essentially you'd either be plugging in small changes that just add additional checks (basically mimicking linters and flags like noImplicitAny) or you're doing something so radical (like the nominal vs structural thing you mention, see #202 for discussion on the particulars there) that you've basically forked the language and have multiple entirely different languages which happen to share the same syntax. You'd be unable to look at a .ts file and understand the semantics of it without figuring out which type system has been applied (you can see similar concerns mentioned here #274) and it would also limit the ability to do certain language features safely (ie any that want to effect emit based on type information).