5 ms·

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymor

let lowerCased = strs!.map(s => s.toLowerCase()); I'm not a big fan of this, it's really starting to change JS semantics. It's not just type annotations anymore + ES6 . It's starting to look like its own language. Some might like that, I do not. They should be a bit more cautious before introducing these features. What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? It's like decorators, they are not in the spec, there is no plan yet to officially had them to the spec, yet, Angular2 which is written in Typescript abuse them. What if in 2 years they are introduced in ES2019 with different semantics ? How Typescript is going to handle that too ?

johnfn 10y ago
This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language. In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.
- h_r 10y ago
  >! is just an inline type coercion. Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.
  - johnfn 10y ago
    When would code with ! ever compile differently than code without ! ?
    - h_r 10y ago
      Umm never? That's not the point. It's not changing (coercing) the type of anything, it's just allowing the call without flagging it as an error. The call at run time might still get passed an undefined and fail. It's like choosing an unsafe partial function in Haskell rather than using a total function that forces you to deal with Maybe. At least that's what it looks like. I've never used typescript or I'd test it right now. I'm on my phone and haven't tried it. (Edit: my answer didn't quite make sense! It's different since without ! it compiles as an error because, in this case, you can't map over undefined. With !, it just ignores that possibility although it could still happen. The compiler cannot verify all run time possibilities since your sum type says it really can be undefined.) (Re edit! Verifying the types vs skipping that verification is not the same thing as coercing the types)
      - johnfn 10y ago
        It's coercing the type from, e.g. String | undefined to String.
        h_r 10y ago
        let lowerCased = (s : string[] | undefined) => s!.map((str : string) => str.toLowerCase()); console.log(lowerCased(['A','B'])); console.log(lowerCased(undefined)); //boom! It doesn't coerce anything. All it does is let the code pass without error. "s!.map" and "s.map" compile to the exact same Javascript code, which means there is no type coercion going on. Are you sure you know what type coercion is? The first log prints out fine and the second blows up, which proves that undefined isn't being coerced to a string[]. If that was the case, the resulting JS would be checking for undefined and probably creating an empty array.
        johnfn 10y ago
        My bad, I meant conversion, not coercion.
rattray 10y ago
Agreed – this may now be my top reason not to use TypeScript (followed by inadequate inference / support for gradual typing, differences from Babel, and a few random features), which I would otherwise very much like to use.
- bcherny 10y ago
  This is a poor reason to not use TS. If in the unlikely worst case scenario the TS team drops/renames the ! syntax at some point, given that these are compile time checks, you will just manually go through a list of compile time errors and fix the issues one by one. More likely scenarios: - They will make the change in a backwards-compatible way - They will release a jscodeshift script to do the upgrade for you - Etc.
  - rattray 10y ago
    Okay, fair. Perhaps I overreacted. I think the general idea of adding syntax outside of declarations really rubs me the wrong way, but perhaps it shouldn't.
Derander 10y ago
TypeScript has dealt with this in the past by adapting to the introduction of `<Foo>` from jsx, which clashed with typescript's casting operator. If this ends up being a problem I'm sure that the TypeScript team will just pick a different syntax. In my experience, the overhead caused by TypeScript is far outweighed by benefits in tooling and confidence that my code works (mostly) after refactors.
smt88 10y ago
I don't plan to use that feature. If they remove or change it, my code will still work.
spankalee 10y ago
AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://github.com/tc39/proposal-decorators/commit/c32ea181569668a6c1ef212c1a85071e2bf53466#diff-3540caefa502006d8a33cb1385720803R19193 https://github.com/tc39/proposal-decorators/commit/c32ea1815...) Even so, I've been pretty impressed with the TypeScript teams ability to manage this kind of change an uncertainty and keep up with and move closer to standard JavaScript where they have been differences. Specifically regarding the `!` operator* , to convert to standard JavaScript just remove the `!` operator, like you would remove a cast or type annotation. It's still within the TypeScript spirit to me. * I personally would have rather seen it either be a type of cast (maybe `<!>strs.map(...);`), or add a null-safe property accessor: `strs?.map(...)` which doesn't assert that `strs` is non-null, but makes the expression null-safe, returning null if `strs` is null.
- TheCoreh 10y ago
  That null-safe property accessor (`?`) is being discussed for ES, and it's reasonable to assume that it will ship eventually. They wouldn't add that and risk having different semantics.
ihsw 10y ago
Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse? I won't even get into generics as that's a whole different can of worms. Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time. TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that. [1] https://flowtype.org/ https://flowtype.org/
- spriggan3 10y ago
  > let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse? The probability is higher for ES to implement async/await than the ! operator. The former is a safe bet, the latter isn't, by a long shot. > Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time. It means that language will break. Not very good if you write large TS codebases today. > TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that. That's your opinion. I'm not interested in Flow. Ultimately TS is successful because it more or less looks like Action Script 3/ES4/JScript.net and javascript itself. Make it too Alien and the people who refused to use Coffee script because of its semantics will not want to use TS. And FYI I use TS today. I may reconsider that.
  - kbenson 10y ago
    > > let x = (id: number, name?: string) => { return; }; > hmm, it would make more sense if it was written like that > > let x = (id: number, name: string?) => { return; }; > But I guess it's more or less ok. But I definitely feel inconfortable with the ! . I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well. In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.
berns 10y ago
Typescript is a superset of Javascript, but it it's not only Javascript plus types. Some features like async/await could end up being implemented differently in Ecmascript. It seems inevitable that there could be incompatibilities in the future. But the same happens with Babel or other transpilers when they introduce features that are not yet standardized.
ceronman 10y ago
Being realistic, it might take more than a decade to see a standard EcmaScript version with type annotations available in all major browsers. Until then, transpiling is the only choice. So I don't think diverging from the (possible) standard is too bad. We don't know how the state of web development will be at that time, and probably the standar won't ever catch up with TypeScript and transpiling will be required for quite a long time until something like WebAssembly really takes off.
tracker1 10y ago
The type definitions in flow are pretty much the same iirc. Also decorators is already an ES proposal, the only concern was the order of application of decorators vs declaration, they've been applied pretty consistently. As to the additional checks for non-null types, I'd say that async/await would be far more welcome at this point... it's one of the few reasons that those using TS are still running their output through babel after. Personally, I'm not a fan of TS, but can see why others would like it... I'm pretty good with ES2016 + Stage-1 via Babel...
bjconlan 10y ago
I agree, I feel like this is becoming kotlin (not a bad thing) but the syntax is quite a divergence from es5+types less so with es6 but your sentiments are bang on

johnfn 10y ago

This post is full of misplaced FUD. > It's not just type annotations anymore + ES6 How not? ! is just an inline type coercion. > What if Ecmascript in the future uses ! as an operator for a totally unrelated purpose ? This seems unlikely because ! is already an operator in JS. But really, this argument could be made against any operator TS uses. What if ES introduces : as an operator? Or if they introduce some sort of ambiguity with the other myriad type definitions? This is not a new issue, and you shouldn't let null checks drive you away from the language. In any case, both null checks and decorators are behind flags. The decorators flag is literally called "experimental decorators". So it's not like the TS team is pretending that it's going to be stable forever.

h_r 10y ago
>! is just an inline type coercion. Are you sure about that? It sounds more like a signal to the compiler to "trust me, I know what I'm doing" and would blow up if you passed undefined anyway. Maybe the author didn't explain it very well. That is, not a type coercion so much as a hint to not bother checking this access.
- johnfn 10y ago
  When would code with ! ever compile differently than code without ! ?
  - h_r 10y ago
    Umm never? That's not the point. It's not changing (coercing) the type of anything, it's just allowing the call without flagging it as an error. The call at run time might still get passed an undefined and fail. It's like choosing an unsafe partial function in Haskell rather than using a total function that forces you to deal with Maybe. At least that's what it looks like. I've never used typescript or I'd test it right now. I'm on my phone and haven't tried it. (Edit: my answer didn't quite make sense! It's different since without ! it compiles as an error because, in this case, you can't map over undefined. With !, it just ignores that possibility although it could still happen. The compiler cannot verify all run time possibilities since your sum type says it really can be undefined.) (Re edit! Verifying the types vs skipping that verification is not the same thing as coercing the types)
    - johnfn 10y ago
      It's coercing the type from, e.g. String | undefined to String.
      - h_r 10y ago
        let lowerCased = (s : string[] | undefined) => s!.map((str : string) => str.toLowerCase()); console.log(lowerCased(['A','B'])); console.log(lowerCased(undefined)); //boom! It doesn't coerce anything. All it does is let the code pass without error. "s!.map" and "s.map" compile to the exact same Javascript code, which means there is no type coercion going on. Are you sure you know what type coercion is? The first log prints out fine and the second blows up, which proves that undefined isn't being coerced to a string[]. If that was the case, the resulting JS would be checking for undefined and probably creating an empty array.
        johnfn 10y ago
        My bad, I meant conversion, not coercion.

rattray 10y ago

Agreed – this may now be my top reason not to use TypeScript (followed by inadequate inference / support for gradual typing, differences from Babel, and a few random features), which I would otherwise very much like to use.

bcherny 10y ago
This is a poor reason to not use TS. If in the unlikely worst case scenario the TS team drops/renames the ! syntax at some point, given that these are compile time checks, you will just manually go through a list of compile time errors and fix the issues one by one. More likely scenarios: - They will make the change in a backwards-compatible way - They will release a jscodeshift script to do the upgrade for you - Etc.
- rattray 10y ago
  Okay, fair. Perhaps I overreacted. I think the general idea of adding syntax outside of declarations really rubs me the wrong way, but perhaps it shouldn't.

Derander 10y ago

TypeScript has dealt with this in the past by adapting to the introduction of `<Foo>` from jsx, which clashed with typescript's casting operator. If this ends up being a problem I'm sure that the TypeScript team will just pick a different syntax. In my experience, the overhead caused by TypeScript is far outweighed by benefits in tooling and confidence that my code works (mostly) after refactors.

smt88 10y ago

I don't plan to use that feature. If they remove or change it, my code will still work.

spankalee 10y ago

AFAIK, this is actually happening with decorators, which have changed a lot in how they're defined (the latest I can find is the actual spec changes: https://github.com/tc39/proposal-decorators/commit/c32ea181569668a6c1ef212c1a85071e2bf53466#diff-3540caefa502006d8a33cb1385720803R19193 https://github.com/tc39/proposal-decorators/commit/c32ea1815...) Even so, I've been pretty impressed with the TypeScript teams ability to manage this kind of change an uncertainty and keep up with and move closer to standard JavaScript where they have been differences. Specifically regarding the `!` operator* , to convert to standard JavaScript just remove the `!` operator, like you would remove a cast or type annotation. It's still within the TypeScript spirit to me. * I personally would have rather seen it either be a type of cast (maybe `<!>strs.map(...);`), or add a null-safe property accessor: `strs?.map(...)` which doesn't assert that `strs` is non-null, but makes the expression null-safe, returning null if `strs` is null.

TheCoreh 10y ago
That null-safe property accessor (`?`) is being discussed for ES, and it's reasonable to assume that it will ship eventually. They wouldn't add that and risk having different semantics.

ihsw 10y ago

Do you have the same complaints about optional parameters too? let x = (id: number, name?: string) => { return; }; Is it abuse to use interfaces as well? They are not present in vanilla JS. How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse? I won't even get into generics as that's a whole different can of worms. Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time. TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that. [1] https://flowtype.org/ https://flowtype.org/

spriggan3 10y ago
> let x = (id: number, name?: string) => { return; }; hmm, it would make more sense if it was written like that > let x = (id: number, name: string?) => { return; }; But I guess it's more or less ok. But I definitely feel inconfortable with the ! . > How about React's move away from React.createClass({}) to ES6 classes extending React.Component? Do they abuse classes? I don't use React. > Async/await is coming too and it will turn JS on its head, does eschewing callbacks for async functions also count as abuse? The probability is higher for ES to implement async/await than the ! operator. The former is a safe bet, the latter isn't, by a long shot. > Microsoft and the TS team have issued a mandate that TypeScript will always be a superset of EcmaScript and if ES2019 includes decorators that are incompatible with TypeScript's then it will be addressed at that time. It means that language will break. Not very good if you write large TS codebases today. > TypeScript was never meant to be just type annotations+ES6, there is Flow[1] for that. That's your opinion. I'm not interested in Flow. Ultimately TS is successful because it more or less looks like Action Script 3/ES4/JScript.net and javascript itself. Make it too Alien and the people who refused to use Coffee script because of its semantics will not want to use TS. And FYI I use TS today. I may reconsider that.
- kbenson 10y ago
  > > let x = (id: number, name?: string) => { return; }; > hmm, it would make more sense if it was written like that > > let x = (id: number, name: string?) => { return; }; > But I guess it's more or less ok. But I definitely feel inconfortable with the ! . I think the point is that typescript currently supports the shown optional parameter syntax, JS could be extended in a conflicting way to that as well. In the end, if you are using something that extends JS and you expect that any code you write will continue to work in future versions and that the tool will be altered to stay as close to the standard JS as possible as extended features are incorporated into vanilla JS, you're most likely deluding yourself. Much better to accept that the tool should either try to match vanilla JS, in which case you must accept that you may need to refactor to update occasionally, or that it will eventually diverge, but your code will continue to work, and choose a tool that implements whatever strategy is acceptable to you.

berns 10y ago

Typescript is a superset of Javascript, but it it's not only Javascript plus types. Some features like async/await could end up being implemented differently in Ecmascript. It seems inevitable that there could be incompatibilities in the future. But the same happens with Babel or other transpilers when they introduce features that are not yet standardized.

ceronman 10y ago

Being realistic, it might take more than a decade to see a standard EcmaScript version with type annotations available in all major browsers. Until then, transpiling is the only choice. So I don't think diverging from the (possible) standard is too bad. We don't know how the state of web development will be at that time, and probably the standar won't ever catch up with TypeScript and transpiling will be required for quite a long time until something like WebAssembly really takes off.

tracker1 10y ago

The type definitions in flow are pretty much the same iirc. Also decorators is already an ES proposal, the only concern was the order of application of decorators vs declaration, they've been applied pretty consistently. As to the additional checks for non-null types, I'd say that async/await would be far more welcome at this point... it's one of the few reasons that those using TS are still running their output through babel after. Personally, I'm not a fan of TS, but can see why others would like it... I'm pretty good with ES2016 + Stage-1 via Babel...

bjconlan 10y ago

I agree, I feel like this is becoming kotlin (not a bad thing) but the syntax is quite a divergence from es5+types less so with es6 but your sentiments are bang on