Functional Programming with TypeScript's Type System

Post by rendall » Sun, Apr 16, 2023, 2:37 PM UTC

PhilipRoman wrote: post #17

rendall wrote: post #15

Earlier quoted context omitted.

Sorry, I don't get it. What do you expect to happen here?

Presumably the issue is that a Readonly shouldn't be a subtype of Foo I should note that I haven't yet had the pleasure of using a language that handles const-ness properly, as Readonly should be neither a subtype nor a supertype of T

Post by globuous » Sun, Apr 16, 2023, 3:01 PM UTC

foepys wrote: post #14

I don't get TypeScript's type system. It is obviously very powerful and can model very complex type constraints. But then you have stuff like this where it is not checking types as I would expect: interface Foo { bar: string; } const f = {bar: "foobar"} as Readonly ; function someFunc(): Foo { return f; // No error or warning, even with all strict flags enabled }

    class Animal {}

    class Dog extends Animal {
        woof() {}
    }

    class Cat extends Animal {
        meow() {}
    }

    let append_animals = (animals: Animal[], animal: Animal) => animals.push(animal)

    let dogs = [new Dog()]
    append_animals(dogs, new Cat())

    dogs.map(dog => dog.woof())

    Uncaught TypeError: dog.woof is not a function

    class Animal:
        pass

    class Dog(Animal):
        pass


    def append_animals(animals: List[Animal], animal: Animal) -> None:
        animals.append(animal)


    dogs = [Dog()]
    append_animals(dogs, Dog())

    $ mypy types.py 
    types.py:16: error: Argument 1 to "append_animals" has incompatible type "List[Dog]"; expected "List[Animal]"
    types.py:16: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
    types.py:16: note: Consider using "Sequence" instead, which is covariant

Post by deathtrader666 » Sun, Apr 16, 2023, 3:13 PM UTC

rektide wrote: post #24

foepys wrote: post #14

I don't get TypeScript's type system. It is obviously very powerful and can model very complex type constraints. But then you have stuff like this where it is not checking types as I would expect: interface Foo { bar: string; } const f = {bar: "foobar"} as Readonly ; function someFunc(): Foo { return f; // No error or warning, even with all strict flags enabled }

Are there other examples of ways TS confounds you? This feels like a "haha, gotcha!" moment. Like Gary Bernhardt's Wat talk, it's one single example that looks extremely silly... but has next to no actual impact on anyone using the language regularly, is like the faintest little quirk. Typescript seems reasonably acceptable. I struggle to think of what I would ask for, what would be significantly massively different…

Post by Shacklz » Sun, Apr 16, 2023, 3:18 PM UTC

globuous wrote: post #23

foepys wrote: post #14

I don't get TypeScript's type system. It is obviously very powerful and can model very complex type constraints. But then you have stuff like this where it is not checking types as I would expect: interface Foo { bar: string; } const f = {bar: "foobar"} as Readonly ; function someFunc(): Foo { return f; // No error or warning, even with all strict flags enabled }

Yeah, there are some weird stuff in typescript, for instance, this typechecks class Animal {} class Dog extends Animal { woof() {} } class Cat extends Animal { meow() {} } let append_animals = (animals: Animal[], animal: Animal) => animals.push(animal) let dogs = [new Dog()] append_animals(dogs, new Cat()) dogs.map(dog => dog.woof()) Which if you evaluate, you'll obviously get: Uncaught TypeError: dog.woof is not a f…

    let append_animals = (animals: T[], animal: T) => animals.push(animal)

Post by wooly_bully » Sun, Apr 16, 2023, 3:44 PM UTC

nkrisc wrote: post #26

As wonderfully absurd as this is, I learned more about TypeScript’s type system from this post than I have from its documentation. Entirely possible that PEBKAC, but I’ve found TypeScript’s documentation to be on the worse end of the programming language documentation quality spectrum.