Making sense of TypeScript using set theory • Hacker News Board

Re: Making sense of TypeScript using set theory

#11

Post by epolanski » Tue, Jan 24, 2023, 4:51 PM UTC

jakelazaroff wrote: post #9

I might be missing something, but isn't this line backwards? > Subtype of type A is a subset of type A. Supertype is a superset. Easy. Subtype of type A is actually a superset of type A, since it contains at least all the properties of A. If you had (contrived example) a Dog class that inherited from an Animal class, Dog would be a sub type of Animal, but its additional properties (say, a bark() method) mean that it…

> Subtype of type A is a subset of type A. Supertype is a superset. Easy.

I think it is correct.

Example:

type A = { a: number }

type B = { a: number, b: number }

B is not a superset of A, it's a subset and subtype of A. You can use B every time you want to use A.

In other words, of all types that can be assigned to A or used in functions and types expecting an A, B is one of those subsets.

type C = { a: number, c: number }

is another subtype of A.

A "subtype" C can be substituted in place of its "supertype" A.

Both C and B are subsets of A, in other words: in the infinite set of values of type A, some can be grouped in a type B or C. C itself is a subtype of A.

Re: Making sense of TypeScript using set theory

#12

Post by madeofpalk » Tue, Jan 24, 2023, 5:03 PM UTC

jax_the_dog wrote: post #8

thoughtspile wrote: post #6

Earlier quoted context omitted.

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record or P extends Promise

How is unknown better than any in this case? If you do not care about the data type, wouldn’t you say that “any” data type is acceptable? If you say “unknown” that means that there is possibly some data type that would break your function.

The problem with using any where you don't care about the type is that someone can come along and make unchecked assumptions about what type it actually is. Unknown is spicier as it'll prevent developers from assuming it's a string or object or something.

Re: Making sense of TypeScript using set theory

#13

Post by thoughtspile » Tue, Jan 24, 2023, 5:04 PM UTC

edgyquant wrote: post #10

thoughtspile wrote: post #6

Earlier quoted context omitted.

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record or P extends Promise

But you have to care about the type with unknown? For instance calling this on an unknown obj.value Will return a type error that value doesn’t exist on unknown. While calling it on an ant is valid typing

Here, you expect obj to have a property called "value", so I'd say you do care about the type of obj. A valid type would be obj: { value: blah }

Re: Making sense of TypeScript using set theory

#14

Post by thoughtspile » Tue, Jan 24, 2023, 5:14 PM UTC

jakelazaroff wrote: post #9

I might be missing something, but isn't this line backwards? > Subtype of type A is a subset of type A. Supertype is a superset. Easy. Subtype of type A is actually a superset of type A, since it contains at least all the properties of A. If you had (contrived example) a Dog class that inherited from an Animal class, Dog would be a sub type of Animal, but its additional properties (say, a bark() method) mean that it…

You're making the same mistake as I sometimes do, thinking in terms of "object shape" or "functionality". Here, I use "subset" in a sense of "all values that belong to Sub also belong to Super", in line with a set-theoretic view of types in the post. Also see subsets on wiki: https://en.wikipedia.org/wiki/Subset

Try this one: A is subset of B iff all the values that belong to A also belong to B. In your example (and in real life), every dog is an animal, so dogs are a subset of animals.

Re: Making sense of TypeScript using set theory

#15

Post by jax_the_dog » Tue, Jan 24, 2023, 5:18 PM UTC

madeofpalk wrote: post #12

jax_the_dog wrote: post #8

Earlier quoted context omitted.

How is unknown better than any in this case? If you do not care about the data type, wouldn’t you say that “any” data type is acceptable? If you say “unknown” that means that there is possibly some data type that would break your function.

The problem with using any where you don't care about the type is that someone can come along and make unchecked assumptions about what type it actually is. Unknown is spicier as it'll prevent developers from assuming it's a string or object or something.

That makes some sense to me.

I’m not a TypeScript dev so I apologize for the stupid question. Is there any functional difference between the two? I.e. is there a case where using Unknown instead of Any will result in some sort of “compile” time error opposed to a runtime?

Re: Making sense of TypeScript using set theory

#16

Post by thoughtspile » Tue, Jan 24, 2023, 5:19 PM UTC

jax_the_dog wrote: post #8

thoughtspile wrote: post #6

Earlier quoted context omitted.

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record or P extends Promise

How is unknown better than any in this case? If you do not care about the data type, wouldn’t you say that “any” data type is acceptable? If you say “unknown” that means that there is possibly some data type that would break your function.

Saying a value is "unknown" means making no assumptions about the value. It might be a null, a number, a function, you don't care because you aren't going to do anything with this value. If you call() it, or read.some.property, TS complains because you're making assumptions about the object that TS did not ensure.

Re: Making sense of TypeScript using set theory

#17

Post by thoughtspile » Tue, Jan 24, 2023, 5:28 PM UTC

jax_the_dog wrote: post #15

madeofpalk wrote: post #12

Earlier quoted context omitted.

The problem with using any where you don't care about the type is that someone can come along and make unchecked assumptions about what type it actually is. Unknown is spicier as it'll prevent developers from assuming it's a string or object or something.

That makes some sense to me. I’m not a TypeScript dev so I apologize for the stupid question. Is there any functional difference between the two? I.e. is there a case where using Unknown instead of Any will result in some sort of “compile” time error opposed to a runtime?

Almost every case where you use the value results in an error with unknown, but not with any:

  let danger: any;
  // These all compile:
  danger(), 9 / danger, danger.access, danger.map(x => x \* 2)

  let safe: unknown;
  // These all explode in TS:
  safe(), 9 / safe, safe.access, safe.map(x => x \* 2)

Re: Making sense of TypeScript using set theory

#18

Post by Danoha » Tue, Jan 24, 2023, 5:30 PM UTC

thoughtspile wrote: post #4

scotty79 wrote: post #2

> Why does 0 | 1 extends 0 ? true : false evaluate to false? Because 'extends' really means 'is assignable to'. I feel like most of the questions from the post might be answered fairly easily by using reasoning of 'is assignable to'. Things assignable to A&B are things assignable to both A and B. Things assignable to A|B are things assignable to A or to B. 'never' means a type that nothing is assignable to and is ass…

Fair enough, "is assignable to" is another synonym for "is subset of". I find it much easier to reason about things I can visualize, like sets, which is why I love my set interpretation. Edit: besides, it's quite unintuitve that "never" is assignable to anything. How can never be something?

Because "never" is an empty set and empty set is a subset of all sets.

Re: Making sense of TypeScript using set theory

#19

Post by madeofpalk » Tue, Jan 24, 2023, 5:32 PM UTC

jax_the_dog wrote: post #15

madeofpalk wrote: post #12

Earlier quoted context omitted.

The problem with using any where you don't care about the type is that someone can come along and make unchecked assumptions about what type it actually is. Unknown is spicier as it'll prevent developers from assuming it's a string or object or something.

That makes some sense to me. I’m not a TypeScript dev so I apologize for the stupid question. Is there any functional difference between the two? I.e. is there a case where using Unknown instead of Any will result in some sort of “compile” time error opposed to a runtime?

Yes - trying to access a property or method on something typed as unknown will (almost?) always result in a compile time error because it's unknown whether the value has that property or not.

https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAd...

Re: Making sense of TypeScript using set theory

#20

Post by hbrn » Tue, Jan 24, 2023, 5:42 PM UTC

jakelazaroff wrote: post #9

I might be missing something, but isn't this line backwards? > Subtype of type A is a subset of type A. Supertype is a superset. Easy. Subtype of type A is actually a superset of type A, since it contains at least all the properties of A. If you had (contrived example) a Dog class that inherited from an Animal class, Dog would be a sub type of Animal, but its additional properties (say, a bark() method) mean that it…

Types are not features, they are constraints.

"at least all the properties of A" means "all of the constraints of A and some more". Subtype of A is more narrow than A, even if it means that object of subtype A has to have more fields.