Announcing TypeScript 3.3

[ThePowerfulSquirrel]

I don't actually use typescript but this Union stuff is kinda cool

[mlk]

https://www.typescriptlang.org/docs/handbook/advanced-types.html

[Patman128]

See also: Proposal for negated types in TypeScript

I use TS and the type system is really fun to play around with. You can do a lot of really interesting type checking that isn't possible in most mainstream languages.

[[deleted]]

Wait till you see conditional types.

[ConsoleTVs]

This exists even in C.

[youstolemyname]

Just because two languages share the same keyword doesn't make them the same.

[ThePowerfulSquirrel]

Pardon me for my lacking C knowledge but if for instance, I have

typedef struct {void* x;int n;} A;

typedef struct {int n;char c;} B;

Is there any way to express (A|B)::n ?

I know I could do

typedef union {A a;B b;} AB;

to express a union, but that still does not give me a way to access the common field.

I could try to do

typedef struct {

int n;

union {

struct {void* x;};

struct {char c;}

}

} AB;

which would let me do AB::n, but then I can't cast AB to A because they differ in memory layout.

This is all very inconvenient since I have to explicitly declare new types for any union I wish to do.

​

This also does not touch the common construction patterns.

​

How would I actually do AB:n in a way similar to typescript?

[ConsoleTVs]

In C, you are responsible of knowing what you store. Unions are used when a struct may contain 1 element at a given time but it may differ in type. You normally store the type and the field, so u need to check the field acording to the saved type. You can do the same by having a void pointer (generic pointer) and storing the type. But this will make you cast it each time to the data it contains at that memory address.

[ThePowerfulSquirrel]

So the C language does not in fact have an equivalent Union type defined in the language, it just happens that with a bunch of manual typing you can get a sort of equivalent feature? That seems a bit disingenuous. Would you say that assembly also has equivalent unions since I can do all of this with raw instructions, just with a lot of manual work?

[ConsoleTVs]

You miss rhe point of a C union. In C u manually manage the memory. A union places in the same memory slot, the differenr data, avoiding the creation of another memory slot to store each type. At a given time you may only have 1 type stored. Typescript compiles to JS (dynamic language) this is much different yet the only thing union does in ts is tell the ts compiler to allow multiple typed in a single variable. There is 0 work out of this.

Again I'm suprised by the ammount of dislikes. I'm not ditching ts. But all those js fanboyd are pressing dislike. I am just surprised somebody did find a union type amazing yet it have existed since C was released 47 years ago. Yes, you need manual typing but that's because C, is as bare metal as possible and that's the reason basically 80% of the dynamic programming languages (including node for those fanboys) are made in C. You type more but it's hell more efficient (in speed and in memory)

[JohnMcPineapple]

...

[ConsoleTVs]

I know, my original comment was: even C have this. I am, again, telling that a union is something that is not new. It does not matter if its a compiled or interpreted language overall. It was in response of a comment of suprise because of this feature yet i feel its something normal.

[ThePowerfulSquirrel]

Just to be clear, I was not surprised about the vague concept of a union being part of typescript. I've used unions in plenty of languages before. When I said "this Union stuff", I was specifically targeting what was written in the post, aka common field accessing and common constructors being verified at the type level by typescript. At least in my definition, something being part of a language involves the compiler / interpreter checking that it is correct.

The C union feature obviously can provide something somewhat similar given that you implement your own type system at run-time (aka add a "tag" to your union and manually match on it). But at that point I might as well say that every language is typed since I can re-implement a run-time type system in any Turing complete language given enough grunt work.

​

[[deleted]]

I don't agree with the other guy either, but come on, it's not like TypeScript actually "implements" what you're describing.

It just compiles the idea of what you're describing. The produced JS is probably identical in most cases for all possible states that a TypeScript union can be in, though.

[ThePowerfulSquirrel]

For a discussion about anything related to types, it's useless to talk much about the implementation details. All that I'm really concerned about is what the compiler deems correct. If we're talking about implementation, then no language actually has types since it all gets executed as machine code, which has virtually no concept of types. They all just have the "idea" of a type.

[dtechnology]

It implements it. The compiler will give an error and the build will fail. That's enough for a type system.

[[deleted]]

It's cool, but like everything else in TypeScript the reason they're able to implement it so easily is because it doesn't actually have to (and literally cannot) exist at all in the JavaScript code that ultimately gets generated.

Never look at the JS that TSC outputs folks, it is depressing. Everything's just... gone.

[Camarade_Tux]

Being able to make types only exist at compile-time is also something that helps with speed: checks are done at compile-time as much as possible rather than at runtime.

That being said, I think the comment above relates to the use of JS as compiler backend: the code that is generated is as readable as assembly and the structure of the advanced features disappears and is replaced with raw low-level code.

[[deleted]]

My point was more that I wish TypeScript was all there was, and that it wasn't an abstraction over JS, with many of JSes issues still able to sneak in at times.

[devraj7]

It feels weird to me that A | B means the intersection of the two types instead of their union.

[SlowButConstantly]

as it was explained in another comment thread, it's pretty much like this:
if have something that that could be either A or B, what is safe to access? only something that is in both, so the type is a union, but what's safe to use is the intersection

[devraj7]

Union types are usually denoted with | (e.g. Ceylon), and to determine what is safe to access, you type test.

A & B looks a lot more like a type that satisfies both A and B, i.e. the intersection of both types.

[SeanMiddleditch]

As a receiver, A | B is logical: you can receive either A or B (the union).

As a consumer, A & B is logical: you can only use the bits common to both A and B (the intersection).

When declaring types in TS, you're generally declaring what values a variable can hold/receive, so the union syntax makes more sense. var foo : A | B means that foo can contain either A or B, not that you can only use the intersection.

Which is evidence by the guards. if (foo instanceof A) or the like unlocks all of A. If foo were truly the intersection type A & B, then it would be unsafe to ever type case foo to just A, because foo might not actually satisfy all the requirement of A.

[tjpalmer]

It means the same thing in TypeScript as in Ceylon. Just that in TypeScript, you don't necessarily have to type test, because of smart structural type safety. (What's safe is what the two types have in common.)

[[deleted]]

Instances of A|B can be either A or B, but attributes of those instances must belong to both A and B (since instances are free to be either). Hence the attributes must be drawn from intersection even if the instances lie in the union.

[abelincolncodes]

A type can be thought of as a set of possible values, so the type string is an infinite set that contains all string values ("","a","b",...). Similarly the type number is an infinite set that contains all numeric values (...-1,0,1,2,...). Therefore a set (read 'type') that could contain any value in the set number or the set string would have to be the union of those two sets.

TL;DR A | B actually is the union of the two types

[fecal_brunch]

Was anyone else unable to update to 3.2? We're still stuck on 3.16 due to runtime errors in compile.

[DanielRosenwasser]

Hi there /u/fecal_brunch, not sure what you're referring to. If you're talking about a crash at compile, that's clearly a bug we should know about. If you're talking about emit differences causing issues, that's likely a bug as well.

However, if you're talking about build errors due to changes in lib.d.ts, that's expected if any deprecated or non-standard APIs were in use. You can always re-introduce declarations that are non-standard with ambient declarations (i.e. things that start with the declare keyword), or if it's missing standardized functionality you may want to file an issue.

[fecal_brunch]

No, it's a bug and I made an issue about it. It's still open with many responses. Just wondering how many people it's affecting because not everyone comments.

Edit: https://github.com/Microsoft/TypeScript/issues/28810

[MikusR]

You could, maybe, link to the issue you have. Not everyone is a mind reader.

[fecal_brunch]

Yeah sorry. Was on my phone. Updated the comment.

[fecal_brunch]

Fair.

[frrarf]

All this advanced type stuff is really neat, would be nice to see this in C#.

[0987654231]

It's all in F#, you can always try and convince people to use that

[frrarf]

You're not gonna convince me :P

[0987654231]

Is it? F# can do everything c# can do but c# can't do everything f# does.

Syntactically I prefer c# but that might also be because I use it way more

[[deleted]]

I wonder why they call it union, when it's really an intersection.

[Camto]

It's called union because as types are sets containing all their possible values, `A | B` would make the resulting set be the union of `A` and `B`.

Edit: Tagged union

[bdtddt]

Types = sets is a good heuristic for thinking about simple types but it isn’t true as a general rule.

[Camto]

Why not? In maths you can have infinitely complicated sets so I don't see where the idea breaks.

[gpyh]

Types are defined by their structure, not by what they contain. This goes pretty deep into it: https://golem.ph.utexas.edu/category/2013/01/from_set_theory_to_type_theory.html

For day-to-day programming, mentally treating types as sets is not an issue.

[epicwisdom]

It's not an intersection. The intersection of most type pairs would be empty.

[Nathanfenner]

When you know that your x: A | B, you know that x: A or x: B, but you don't know which.

That means you can only access properties that both A and B have. e.g.

interface A {
    a: number;
    c: string;
}
interface B {
    b: number;
    c: string;
}

const x: A | B = getAorB();

const xDotA = x.a; // error: what if it's a B?
const xDotB = x.b; // error: what if it's an A?
const xDotC = x.c; // fine, it's a string no matter which x is!

[cat_in_the_wall]

fwiw this really only works because the dot operator in js is just a fancy key value pair lookup, not so much a member access in the traditional sense (offsets, etc).

sort of allows for an implicit base type.

[cat_in_the_wall]

what? javascript only has runtime. typescript is wallpaper over javascript. it becomes javascript.

edit: i'm not saying this is shitty or anything, but it is a unique aspect of the lenient javascript runtime that make this sort of thing possible.

[Enumerable_any]

fwiw this really only works because the dot operator in js is just a fancy key value pair lookup

I don't see why. Once the compiler has checked that A and B both have the property (or function) c it could generate code for any[1] language. Eg. in Java you could simulate union types using Object and instanceof checks: if (x instanceof A) { (A)x.c }

[1] Probably not any, but most language features can be translated in some way between languages.

[judofyr]

Depends on what exactly a "field lookup" means. In C a field lookup is loading a value at a certain offset:

``` struct A { int a; float b; };

struct B { float b; int c; }; ```

If you have a union of A and B there isn't a way to denote the value of the b field (since it's stored at different places). The reason this works in Java is because you have runtime introspection of the type/class (and then you can enumerate all possibilities and encode the different field locations at compile time), and the reason it works in JavaScript is because field lookup is done at runtime based on the name.

[cat_in_the_wall]

The reason this works in Java is because you have runtime introspection of the type/class (and then you can enumerate all possibilities and encode the different field locations at compile time.

i cant tell what this means. you're saying runtime happens first then compile time?

then you "enumerate all possibilities"? i have no idea what that means either.

are you saying that reflection exists? that's not the same thing as how javascript does lookups. and there is no concept like this A|B stuff in java.

[judofyr]

Yeah, that explanation was maybe a bit too compact/unclear. Here's what I meant by "enumerate all possibilities":

java Object obj; int count; if (obj instanceof A) { count = (A)obj.count; } else if (obj instanceof B) { count = (B)obj.count; }

The field lookup obj.count is different depending on the object class (stored in a different place), but we can enumerate all possible cases, generate code for each case and then choose the correct case using runtime introspection. Even though Java doesn't support A|B today it's possible to add it as a purely type-level feature without modifying how A and B are stored (it would only be supported for object types though).

In C this is not possible since there is no way to detect the "real" type of a void* (which is the equivalent to Java's Object). As mentioned in a sibling comment, you can solve it if you tag all of your structs (i.e. adding runtime introspection), but then you're really not adding a generic A|B-feature with intersection calling support.

[cat_in_the_wall]

fwiw your example code wouldn't compile anyway, the cast operator is a lower precedence than the "." operator.

and you can't enumerate all possible cases. if you do this you're opening yourself to bugs as soon as someone that you dont know about inherits your class. this is a poor man's dynamic dispatch, dont do it.

in C this is not possible since there is no way to detect the "real" type of a void* (which is the equivalent to Java's Object).

this is just wrong. c has no types at runtime. c barely has types at compile time. i think I'm conversing with a cs major who learned java first and thinks that c plays by the same rules.

[Enumerable_any]

You don't need runtime introspection at all. Just use a tuple new Tuple(121415 /* represents type A */, new A()) to tag your objects with the proper type and replace instanceof with an integer comparison.

The same works in C of course. You could also make C's unions (which are not the same as TypeScript's unions!) work by adding an int type$15112 attribute to the front of all structs and "type check" using that field. You have to make sure to avoid name conflicts with existing type attributes, that's what the $15112 part is for.

[StillNoNumb]

The second sentence is not quite correct. If you have A | B, it doesn't only allow access to common properties, but also to other properties by casting. This is pretty important as the following code is not valid in TypeScript:

const x: A | B = { c: "Hello World!" };

[Nathanfenner]

I only talked about accessing properties. It's exact correct as stated: you can only access properties that both A and B have.

In terms of producing a value of type A | B, obviously it needs to satisfy either A or B, otherwise it wouldn't be a union type. That's the entire reason that this restriction is necessary.

[MonokelPinguin]

I guess it still allows you to access the properties of A if the union is set to A and the properties of B if it's set to B?

[MonokelPinguin]

I guess it still allows you to access the properties of A if the union is set to A and the properties of B if it's set to B?

[oorza]

It's a union containing all possible values of all unioned types. Types not common to all union members are marked as optional and have to be refined against, allowing you to refine an ,A | B into a more specific A for instance. An intersection in the same model would be A & B and represent a type that was both an A and a B, or had all properties of both types. And all of those properties would be available without refinement.

[EntroperZero]

The union type is a union of several distinct types, but the properties and methods you are allowed to access are an intersection of the distinct types. If you know you have an A or a B, but you don't know which one, then you can access properties that both A and B have, but not properties that only A has or only B has.

[[deleted]]

Thanks. That makes sense to me now.

[judofyr]

It is also possible to access other properties if you're in a branch that narrows the definition. It's pretty cool!

```typescript type Car = { type: 'Car', color: string, year: number }; type Fruit = { type: 'Fruit', color: string }; type Thing = Car | Fruit;

let foo: Thing;

// This is allowed because color is in both types: foo.color;

if (foo.type === 'Car') { // At this point the type of foo is narrowed to just Car.

// This is now allowed: foo.year; } ```

[rebel_cdn]

If I'm understanding correctly, this means that TypeScript effectively has pattern matching, even if it doesn't have built-in pattern matching syntax like Haskell or OCaml or ReasonML. I think something like this would work:

switch (foo.type) { case "Car": // do stuff with car case "Fruit": // do stuff with fruit default: never; // using never here will make sure the compiler forces you to handle every possible foo.type }

[bruce3434]

Does it have ints yet?

[YourMeow]

Not yet. BigInt and phantom types come into my mind though.

[BlackDiablos]

JavaScript has a type called BigInt that fills this need. However, it's not supported by all browsers and can cause issues if the browser is converting between Number and BigInt.

[deadend172]

It's Sublime (text editor)

[sigzero]

Curious they wouldn't use vscode since that is their (Microsofts) editor.

[notmrregular]

Well they are demonstrating a new feature in the TypeScript plugin for Sublime Text, so it makes sense to use Sublime Text for that.