-
Notifications
You must be signed in to change notification settings - Fork 44
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
Which parts of the proposal should've native support from JavaScript? #196
Comments
5.
|
It may seem like I'm focusing on the negatives. I'm just trying to consider a class of people who don't want or can't use static types annotations for reasons. Howwill they can continue using JS without or with less friction? E.g. how would they need to adjust code they've imported or copied? Would it be easy to focus on implementation if tag soup is inlined or pre-lined (like JSDoc)? In short summary: a) b) Also, separation of concerns. I'd think the concern of specifying types should not be mixed up in the same place with the concern of implementation. Think haskellian, two lines instead of one:
c) With regard to run time, E.g. if I want to have a safe default, I'd use
With regard to compile time, same argument as b) |
The simpler reason why I'm reminded of So far comment-based approaches remain the only ones which solve for backwards compatibility and for truly optional adoption. |
Let's find out which part of TypeScript, Flow, etc can be a part of JavaScript without type annotations. Which features of TypeScript, Flow, etc can be used without radically changing the syntax of JavaScript?
1. Interfaces have their spot in JavaScript.
It's reasonable to have
interface
language construct in JavaScript, because it's not necessary restricted to type checkers! in a way that aninterface
can be declared without any type annotation. That's it. Interfaces are somehow abstract classes, and they can be used to help us to declare other classes. On the other hand, we needimplements
keyword to implement interfaces within classes. Fortunately bothinterface
andimplements
have been reserved keywords in JavaScript for the future use, so there will not be any source compatibility issue at all. For example:Also with the native support from JavaScript (not as comment), we may
import
andexport
interfaces similar to classes.2. Optional arguments and properties with
?:
syntaxBoth of them can be safely ignored even without type annotations:
EDIT: Ternary operators cannot be in argument list of function declarations. So
arg?
doesn't break any JavaScript program.3. Non-nullable assertions with
!.
operatorIt's complementary to
?.
operator:4. Generic argument list
The
<
and>
operators are not allowed in class, function and variable declarations. So JavaScript can treat them as comment instead of reporting a syntax error:Which features from TypeScript, Flow, etc are too much related to type annotations?
type
(in TypeScript, Flow, etc) andopaque type
(in Flow) features are definitely too much related to type annotations.satisfies
andas
features in TypeScript, should be treated as:
-style comments, because they are extensively related to types. Respectively their syntax can be changed to:(EXPR: satisfies TYPE)
(EXPR: as TYPE)
In this way, both
satisfies
andas
are not necessary to be keywords. JavaScript syntax should not be changed as much as possible. New keywords may make some existing programs to break.And any other part of the syntax from TypeScript, Flow, etc which are for type annotations, should be changed to
:comment
syntax in JavaScript (with simple rules as much as possible).The text was updated successfully, but these errors were encountered: