Does Number.isInteger() still not serve as a Type Guard? https://github.com/microsoft/TypeScript/issues/21199#issueco...
In TypeScript, type guards are considered to be exhaustive, so if you have a string | number and check it against a function that says it returns "x is number", then TypeScript will think that in the negative case, it's a string. If isInteger was marked as a type guard, then you could write code like this: function f(s: string | number) { if (!Number.isInteger(s)) { console.log(s.substring(0, 0)); } } which is clearl…
TypeScript 5.0
121–130 of 332 posts
Re: TypeScript 5.0
#122I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.
Re: TypeScript 5.0
#123Earlier quoted context omitted.
Until WASM can touch the DOM you’re still going to need JS (and hence, TS).
In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.
Re: TypeScript 5.0
#124Your regular reminder, that it’s just a regular release, since typescript don’t follow semver. After 4.9 goes 5.0
Re: TypeScript 5.0
#125In that case, they can remove all JS weirdness from it, simplify it, add a proper standard library, and add other good parts from other (especially functional) languages to it.
My wish list for such a language (in addition to what is already in Typescript), in no particular order:
- Generic object literals (Why should generic type inference be limited to functions?)
- Deep support for an alternative to exceptions using a Failable type
- Localizable keywords (Why should programming languages be tools of cultural hegemony?)
- Dependent types, with no real distinction between values and types (At a certain point, Typescript’s type system begins to look like a separate Turing-complete language within a language. It’s probably time to do away with this dichotomy entirely somehow)
- Higher-kinded types (This is a pending issue in TS since 2014)
- JSX built-in without the need for any React-like dependency (No need to use it if you don’t like it; in the general sense, it’s just syntactic sugar for composing function invocations)
- No return necessary (the last expression in a block is returned). Thus every flow control construct _can_ (but does not have to) be an expression.
- No null, undefined, or any of all that, in favor of using a Maybe type
- Proper decimal types (it’s shameful for a language to be without it now)
- A reasonably extensive standard library (Math, Stats, Collections (pull & push), String, Objects, Date/Time, Async, Functional, DOM, etc.)
That would be getting close to the perfect language for me.
Re: TypeScript 5.0
#126I’m always surprised by how much others like typescript. Out of all the languages I have to use, typescript is the one that feels the most like pulling teeth. Maybe I just don’t know how bad it truly was to work with a really large JavaScript project without types and that’s why people love it, but without that experience it just feels like all the hassle of types without most of their benefits.
Re: TypeScript 5.0
#127Earlier quoted context omitted.
I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), trai…
Have you tried Crystal? I got the same "oh, they got this right too" feeling about everything as well.
Re: TypeScript 5.0
#128Slowly TS becomes a quirky Java. I for one am not cheering annotations (uhum decorators). I understand their power, but I preemptively lament the all the project that will over use them (yeah looking at you Hibernate).
TS also lets you do what Babel is for, translate the JS to earlier versions of JS. However, that has nothing to do with TypeScript itself, if your target runtimes support all the ECMAscript features you use you don't need to transpile, you only need to remove the type annotations, none of which are code (apart from the leftovers from early days mentioned above).
So you would need to complain about ECMAscript. The decorators in this release, for example, are there because it moved to a stage 3 ECMAscript proposal last year, which means TypeScript must implement it now - because TS ECMAscript and not its own language. So they need to support all of at least stage 3 proposals of ECMAscript.
Re: TypeScript 5.0
#129The missing feature I want most is type narrowing across chained functions like: arr.filter(a => a.kind === „bar“).map(a => /* a should now be of type Bar just like in a branch */)
``` arr.filter((a: A): a is A & { kind: 'bar'} => a.kind === 'bar') ```
If you define:
``` function isKind(kind: K): (a: A) => a is A & { kind: K } { return (a): a is A & { kind: K } => a.kind === kind; } ```
Then you can write:
``` arr.filter(isKind('bar')) ```
and get a properly narrowed return type array
Re: TypeScript 5.0
#130I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the…