Live data from Hacker News

TypeScript 3.7

typescriptlang.org

111–120 of 167 posts

Re: TypeScript 3.7

#111

Earlier quoted context omitted.

&& ?. || ?? It's a shame JS at the beginning doubled down on the "billon dollar mistake" [1] with two(!) kinds of NULL instead of just using Maybe/Option. Ah well, if it were good it wouldn't be popular :/ [1] https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

Sorry, JS? While JS might get this stuff one day, these language features are for TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. Speaking of which, optional chaining and null coalescence are core language features of some very good languages. K…

These features are copied from TC39 proposals for JavaScript. Presumably they were deemed safe to add to TS now that they have reached Stage 3 as JS proposals.

https://github.com/tc39/proposals

Re: TypeScript 3.7

#112
post #44

I feel really excited about 3.7. Optional chaining and null coalescing will clean up a TON of code. ... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.

Indeed, how can you declare a list with some elements nullable, and some not? The result should instead be a tuple, but IDK how well tuple size inference would work in a case like that.

Having it be a tuple would require variadic generics, wouldn't it?

Re: TypeScript 3.7

#113

Earlier quoted context omitted.

Sorry, JS? While JS might get this stuff one day, these language features are for TypeScript which is its own language. It's strongly typed and just happens to interop with and in some scenarios transpile down to JavaScript. It's whole existence is to deal with that billion dollar mistake you mentioned. Speaking of which, optional chaining and null coalescence are core language features of some very good languages. K…

These features are copied from TC39 proposals for JavaScript. Presumably they were deemed safe to add to TS now that they have reached Stage 3 as JS proposals. https://github.com/tc39/proposals

Not so much 'copied', considering it was the TS team that has gotten them added to JS. They just didn't want to commit to anything in the TS codebase that wasn't at least stage 3 in JS.

Re: TypeScript 3.7

#114
post #90

I'm a big fan of the new operators. One of my remaining gripes with Javascript/Typescript is the try/catch mess around await. It makes assignment of const a pain for async calls that may reject. e.g. let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } // at this point result is `SomeType | undefined` if (result) { doSomething(result); } I really want some ki…

I use await-to-js[1] to clean this stuff up. You can pair it with destructuring arrays like so: const [err, result] = await to(funcThatReturnSomeType()); if(err) doSomethingWithErr(err); doSomething(result); [1] https://www.npmjs.com/package/await-to-js

Good old Go-style

Re: TypeScript 3.7

#115

I feel really excited about 3.7. Optional chaining and null coalescing will clean up a TON of code. ... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.

The problem is that Promise.all stopped infering tuple types. Promise.all([() => A, () => B]) should be Promise but is now Promise. This issue is being tracked here and a fix seems to be already in the making: https://github.com/microsoft/TypeScript/issues/33752 https://github.com/microsoft/TypeScript/pull/33707

Re: TypeScript 3.7

#116

I'm a big fan of the new operators. One of my remaining gripes with Javascript/Typescript is the try/catch mess around await. It makes assignment of const a pain for async calls that may reject. e.g. let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } // at this point result is `SomeType | undefined` if (result) { doSomething(result); } I really want some ki…

IIFEs are an option: const result = await (() => { try { return funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } })();

That is so much harder to read though...

Re: TypeScript 3.7

#117
post #113

Earlier quoted context omitted.

These features are copied from TC39 proposals for JavaScript. Presumably they were deemed safe to add to TS now that they have reached Stage 3 as JS proposals. https://github.com/tc39/proposals

Not so much 'copied', considering it was the TS team that has gotten them added to JS. They just didn't want to commit to anything in the TS codebase that wasn't at least stage 3 in JS.

Out of curiosity, have there been features that were thought to be part of JS one day, added by TypeScript, and then abandoned for JS again, leading TS to rip them out as well? Or do such vestiges remain in TypeScript and have to be changed into different constructs on compilation?

Re: TypeScript 3.7

#119

I'm a big fan of the new operators. One of my remaining gripes with Javascript/Typescript is the try/catch mess around await. It makes assignment of const a pain for async calls that may reject. e.g. let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } // at this point result is `SomeType | undefined` if (result) { doSomething(result); } I really want some ki…

IIFEs are an option: const result = await (() => { try { return funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } })();

I don't think this is correct, as the try catch will only catch errors that happen while returning the promise, not awaiting it; you need to do this:

    const result = await (async () => {
      try {
        return await funcThatReturnSomeType();
      } catch (err) {
        doSomethingWithErr(err);
      }
    })();

Re: TypeScript 3.7

#120
post #117
post #113

Earlier quoted context omitted.

Not so much 'copied', considering it was the TS team that has gotten them added to JS. They just didn't want to commit to anything in the TS codebase that wasn't at least stage 3 in JS.

Out of curiosity, have there been features that were thought to be part of JS one day, added by TypeScript, and then abandoned for JS again, leading TS to rip them out as well? Or do such vestiges remain in TypeScript and have to be changed into different constructs on compilation?

TypeScript has incompatibilities with the private keyword and decorators. I don't think they have a strategy to deprecate.
Post reply on HN