Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.7

typescriptlang.org

Post reply on HN
Print view View original

161–167 of 167 posts

Re: TypeScript 3.7

#161

Post by smichel17 »

twh270 wrote: post #25
dashwav wrote: post #13

I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.

I can almost guarantee you'll like it. Kotlin has this same feature and I've found it saves a good amount of boilerplate null checking when inter-operating with lousy legacy Java code.

It's also useful as a convenient syntax for maybes.

Re: TypeScript 3.7

#162

Post by nsonha »

realharo wrote: post #145
int_19h wrote: post #98

Earlier quoted context omitted.

The use of ?? and ?. for null coalescing and null chaining comes from C#, and predates Dart.

According to https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... , ?. was only added to C# 6.0, in 2015. Groovy had ?. in at least 2005. Then there were CoffeeScript, Kotlin, Swift and a bunch of others in the meantime. Not that it matters :)

coffeescript

Re: TypeScript 3.7

#163

Post by nsonha »

lucasmullens wrote: post #62
grapehut wrote: post #41

Earlier quoted context omitted.

Definitely. It's a shame that dart gets so much unwarranted hate. I mean, I also think it's an absolutely awful language but it's really proven to be a valuable source of data for what other programming languages should do and perhaps more importantly: not do. I really hope we see a lot more things like Dart, and not so much negativity.

I haven't heard this general hatred of Dart. Why do you think it's an absolutely awful language?

not awful, more like mediocre and has no reason to exist

Re: TypeScript 3.7

#164

Post by eyelidlessness »

autora wrote: post #149
KuhlMensch wrote: post #127

Earlier quoted context omitted.

This does not necessarily invalidate your wider points, but just FYI: > It does not interop with JavaScript. Hm, this depends on your definition of "interop". My JavaScript and TypeScript are languages that exchange information. The execution model ultimately involves JavaScript when I use tsc, but ultimately it also includes an interpreter. My user-space syntax doesn't care. > There is no such thing as a TypeScript…

>Not being glib, just a heaps up: https://github.com/denoland/deno interesting thanks for the heads up - my assumption is though that this is just a wrapper over a V8 engine with typescript compilation on the fly? Does that make it a TypeScript runtime or not?

V8 is a JavaScript runtime that compiles JavaScript on the fly, so it seems reasonable to say that a runtime that compiles TypeScript on the fly is a TypeScript runtime.

Re: TypeScript 3.7

#165

Post by eyelidlessness »

davnicwil wrote: post #144
paulddraper wrote: post #104

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...

I don't see it as two kinds of null, there is a null value, and then there is the fact that no value has ever been defined, which is undefined. It can be useful to have the latter case distinguished in a dynamic language because it can enable certain powerful patterns. At the end of the day, compressing both these cases to a single concept of null would be lossy. This may have certain advantageous implications for si…

There is yet a third type of missing value in JS: empty array slot. This appears when you create an array with a length but no values for indexes in that length, e.g. `new Array(100)`.

Edit: also `undefined` is a value in JS as well.

Re: TypeScript 3.7

#166

Post by btown »

desert_boi wrote: post #97
nikeee wrote: post #79

Earlier quoted context omitted.

You can also get rid of `if(result){}` by setting the return type of "doSomethingWithErr" to "never": function doSomethingWithErr(err: any): never { throw new Error("Oops"); } let result: SomeType; try { result = await funcThatReturnSomeType(); } catch (err) { doSomethingWithErr(err); } // because doSomethingWithErr has return type "never", result will be definitely assigned. doSomething(result); ..or just return in…

Interestingly when I was encountering this myself recently, I discovered that JS finally blocks can return after a function has nominally already returned. Consider the following closure. (() => { try { // finally will return prior to this console.log console.log('this try was executed and the return ignored') return 'try block' } catch (e) { return 'error block' } finally { return 'finally block' } })()

This is how it's specified for anyone interested: https://stackoverflow.com/a/3838130/298073

Re: TypeScript 3.7

#167

Post by yawaramin »

saurik wrote: post #119
yawaramin wrote: post #85

Earlier quoted context omitted.

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); } })();

You may be right, proving the old adage that the best way to get an answer on the internet is to post a wrong answer ;-)
Post reply on HN