Hacker News Reader

I think that interfaces in TypeScript unfortunately contribute to that confusion. I can do

  interface Point2D {
    x: number
    y: number
  }

And then I can do

  interface Point3D extends Point2D {
    z: number
  }

And that "extends" really throws off many people because in reality the type of Point2D is implicitly

  {
    x: number
    y: number
    [anything_else in string]: unknown
  }

So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. Fortunately, the type notation is less misleading because I can do

  type Point3D = Point2D & {
    z: number
  }

Without any misleading "extensions".

It seems like it all stems from the tight coupling between types and classes in a typical OOP paradigm. When you create a class Animal you create a type Animal that should conform to specific rules, but when you instantiate that class you create an object that conforms to a narrower set of rules. E.g. an object instantiated from class Animal won't be able to woof() even though the type "Animal" easily allows it. This leads to the mental model of "extending" base class with new fields and methods. And even though it indeed extends the class Animal, it narrows the type Animal.

"Extends" does not mean it extends the type to contain more members, it means it extends instances to have more properties, thereby creating a subset or subtype.

Perhaps it is confusing that TypeScript uses terms from both set-theory (union, intersection) and OO (extends, implements). But there is no contradiction.

Right, my point is that it is confusing.

> So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it.

The notation suggests that it extends the definition with additional restrictions. Which it does. Which, yes, produces a narrower scope. That’s how definitions work.

In mathematical logic, for example, saying that A is an elementary substructure of B is equivalent to saying that B is an elementary extension of A. The same with subfields and extension fields. Those concepts are opposite.

Usually in OOP you extend a class with additional implementation. Intersection of types means union of their members and vice versa. Getting into a situation where extending X gives you a sub-X seems like an unfortunate case of mixing two mental models that behave in a dual manner.

This depends on what you mean by "property".

Universal properties are preserved "downwards" i.e. in subsets (more properly, substructures). Existential properties are preserved upwards, i.e. in supersets (extensions).

For example, the property "there exists an element that equals itself when added to itself" is preserved in a superset.

If you have sentences that mix quantifiers (e.g. "for all epsilon, there is a delta ..." or even just "every element has an inverse"), then all bets are off.

The branch of mathematics where this is studied (and rigorously proven) is model theory.

edit: I guess by "property" (given the context of the discussion) you might just mean "function" or "method", in which case, yes, a function defined on a set is also defined on a subset but not necessarily vice versa, so there are in a certain sense "more" functions defined on the subset.

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript?

https://en.wikipedia.org/wiki/TypeScript

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself is a strict superset of Javascript.

> Typescript is designed to accept any valid Javascript program

That's not strictly true though. `a<b,c>(d)` is valid Javascript but Typescript treats it as a different syntactic construct[0].

[0] https://www.typescriptlang.org/play?#code/C4TwDgpgBARlC8UB2B...

With these declarations your fragment is valid in both JavaScript and TypeScript:

    class b {}
    class c {}
    const d = JSON.parse
    const a = Promise.prototype.then.bind(Promise.resolve(1))

    console.log(a<b,c>(d))
    // TS output: Promise { <state>: "pending" }
    // JS output: false false

TS playground: https://tsplay.dev/mAdeZN

It is strictly true. a<b,c>(d) is only valid JavaScript iff a, b, c, and d are values. The TypeScript expression a<b,c>(d) where b and c are types is NOT JavaScript, since JavaScript doesn't have type expressions. The statement that every JavaScript program is a valid TypeScript program does not imply the opposite - hence strict superset.

edit: there is indeed an edge case with the parentheses that throws the TypeScript parser off even if only values are involved.

See the sibling comment from oblosys for an example where the exact same code can give different results in vanilla JS vs after a tsc pass. As you can see there, the problem is that an identifier can simultaneously represent a value and a type.

This is different than JSX or hashbang, where the set of non-JS syntax cannot legally overlap with existing syntax/semantics.

I guess this is a distinction between intent and results. Typescript is intended to be a strict superset of Javascript. In practice, there are edge cases like these.

Lol, this is brilliant!

Here are 3 statements that were made in this thread:

- typescript is a superset of javascript

- superset of objects can only have the same or fewer properties

- Typescript contains all the rules of Javascript, and then adds some more

Do you see where the confusion is coming from?

> that also means the language specification itself is a strict superset of Javascript

This is where I disagree.

TS as a language has more properties than JS, but less rules. I.e. you can create Javascript language out of Typescript by adding more rules (constraints).

But TS as a spec has more rules than JS spec.

TS as a language is a superset of JS language. TS as a spec is a rough subset of JS spec.

You're making this harder than it actually is by conflating a bunch of things, comparing apples and oranges. Sets defined by type vs sets defined by lists of properties, specs, rules etc.

For types, just draw the Venn diagrams:

- The set of objects of Type A is entirely within the set of objects of Subtype of A. Subtype of A is the superset.

- the set of things that are Dogs (class or real world) is entirely within the set of things that are Animals.

- the set of things that are Javascript programs is entirely within the set of things that are Typescript programs.

> Sets defined by type vs sets defined by lists of properties, specs, rules etc.

Recursive explanations are useless: "types are just sets defined by types". That's why we are trying to define them through other means.

Also TS has structural type system, which is literally about comparing properties.

That's not what GP wrote - they wrote that there is a difference between "the set of all instances of type A" and "the set of all properties satisfied by all instances of type A". There's nothing recursive about that. And this is all completely independent of the question of whether a language is structurally or nominally typed.

(butting in)

What is recursive about the parent comment?

It's recursive in the context of "making sense of TS using set theory". If you understand sets, but not types, statements about "sets defined by types" are meaningless.

> superset of objects can only have the same or fewer properties

This is potentially misleading. A superset will include more objects and therefore may include more individual properties. But type checking is about what can be safely assumed about all members of a set, so more different objects in the set will constrain the type more.

Object is a superset of Date because the set of objects includes alle Dates but also things which are not dates and have different properties. But in the context of type checking, object is more constrained because there are fewer properties which all members of the set are guaranteed to have.

Typescript is a superset of Javascript because all Javascript programs are also Typescript programs. There is no contradiction.

> object is more constrained because there are fewer properties which all members of the set are guaranteed to have.

In my mind it's the opposite: object is less constrained, because there are fewer requirements you need to fulfill to be considered an object. Object type is very permissive.

The more constrained type is, the fewer objects it's set will contain. The more constrained the type is, the more rules it enforces. Seems intuitive, isn't it?

TypeScript is a superset of JavaScript because any JavaScript program is also a Typescript program but not vice versa. There is no contradiction.

> TS as a language is a superset of JS language. TS as a spec is a rough subset of JS spec.

This does not make any sense. A spec which fully describes TypeScript including runtime behavior would include the JavaScript spec and therefore be a superset. The TypeScript spec itself is in no way a subset of the JS spec, sine it descries features and syntax which does not exist in vanilla JavaScript.

This is how you should think about it: Spec > Language > Code.

Code is an instance of Language (and in structural typing land it can be compatible with multiple languages). Language is an instance (implementation) of Spec.

> sine it descries features and syntax which does not exist in vanilla JavaScript

That's exactly why TS spec is a subset. Take example from the article:

  type B = true extends boolean ? 1 : 0; // 1

Type B is a subset of boolean, meaning there are less objects in the world that satisfy type B.

There are less language implementations in the world that satisfy TS spec than JS spec. Every language that satisfies TS spec also satisfies JS spec. TS spec adds more constraints (requirements) to language implementation compared to JS spec, it is more strict, therefore it's a subset.

So you are saying the implementation of the Typescript language are a subset of all JavaScript implementations? I guess that is true in a certain sense. But this does not contradict the fact that TypeScript as a language is a superset of JavaScript - rather it follows logically.

(Although in reality the Typescript implementation is a preprocessor, intended to use together with a regular JavaScript engine.)

Kind of. The language gets confusing because we use subset and superset next to each other, but we put different meaning on them.

{foo: number, bar: string} as type is a subset of both {foo: number} and {bar: string}. It requires it's members to have both properties. You can construct this type using intersection:

  type Foo = {foo: number}
  type Bar = {bar: string}
  type FooBar = foo & bar

{foo: 1, bar: 'hello'} as object is a superset of {foo: 1} and {bar: 'hello'}. It contains both properties. We can construct this object using union (I use pipe instead of spread to illustrate the idea):

  let foo = {foo: 1}
  let bar = {bar: 'hello'}
  let foobar = foo | bar

When I'm saying TS is a superset of JS, I mean it in the object sense. It has all the properties of JS, and some more. All JS programs are also TS programs, but not vice versa. There's more JS programs in the world than TS programs.

When I'm saying TS spec is a subset of JS spec, I mean it in a type sense. Language is an instance of a spec. TS spec has all of the requirements of JS spec, and some more. All TS implementations (languages) will contain JS implementations, but not vice versa. There's more JS implementations in the world, than TS implementations (assuming you can build TS as compiler/interpreter instead of transpiler).

> All JS programs are also TS programs, but not vice versa. There's more JS programs in the world than TS programs.

I think you are confusing terminology, because those two statements are contradictory.

You're absolutely right, last statement should be inverted. I think meant to say something else, but at this point I don't remember what it was.

In any case, the TS spec is a superset of the JS spec, since it incorporates the JS spec. If you don't consider the JS spec as part of the TS spec then they are disjoint sets. But the TS spec cannot be a subset of the JS spec since that would mean it removed some parts of the JS spec, which is not the case.

You are right, the statements are contradictory. It's strange to see how nobody questions marketing buzzwords from Microsoft.

What "marketing buzzwords" are you referring to?

Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}.

The subset is {red}.

Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

> Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A", and there's no real difference between that and saying the superset doesn't have the property at all (I could say "my subset consists of shiny marbles; my subset has the property that they're shiny and my superset does not have that property", or I could say "my subset has the property that shininess is true, and my superset has the property that shininess is true or false", and there isn't really any difference once you get down to the set-theoretic level - a property is just a boolean-valued function). The only superset that has exactly the same properties as the set itself is the set itself (since "is a member of the subset" is a valid property).

Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property. The original post claimed that the superset always has the same or fewer properties. I was questioning whether this was true.

You've mentioned that it is generally true, which seems like a better way to describe the concept.

-- edit: I understand now, in my example above the subset must contain a property by which it could be identified. The original rainbow property is lost but a new one is gained.

> Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property.

You're mixing levels. The property is something satisfied by members of the set, not by the set as a whole.

The way "subset of properties" is being used here is loose and that's where the confusion is arising from. If we want to be a bit more rigorous:

* Define O as a set of possible (finite) objects

* Define properties as functions P: O -> {0, 1}

* A given property then is a function of the form p(o) = 1 for all o in O that satisfy the property p.

You can use property functions to generate subsets of O ({ o for o in O where p(o) = 1 }). The intersection of these generated subsets of multiple property functions will be strict subsets (strictly "smaller" as O is finite) of O as long as at least one property function is not of the form P(o) = 1 for * in O. Generally assuming that each property function generates strict subsets, applying more properties derives a smaller intersection set. That's all.

Thanks for that, it makes sense using your definition. I'm curious as to whether you agree with the parent comment that the subset could contain 'more' properties than the superset.

My understanding from your stricter definition is that (by definition) all potential properties (o for o in O where p(o) = 1) must be contained within O.

If the answer is that the superset O has fewer properties where every p(o) = 1 then I agree, and I was overthinking it

> If the answer is that the superset O has fewer properties where every p(o) = 1 then I agree, and I was overthinking it

It's just this honestly. A superset will generally have fewer properties which apply across the whole set.