Hacker News Reader

Comment by leetrout | Hacker News Reader

The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type.

The correct use of:

  printDog({
      breed: "Airedale",
      age: 3
  })

is to explicitly cast it:

  printDog({
      breed: "Airedale",
      age: 3
  } as Dog)

[0] https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p...

[1] https://www.typescriptlang.org/docs/handbook/advanced-types....

View on HN

Casting can hide errors. It's better to assign it to a variable first that has a type declaration.

    const dog: Dog = {
        breed: "Airedale",
        age: 3
    }
    printDog(dog)

An IIFE is safe too:

    printDog(((): Dog => ({
        breed: "Airedale",
        age: 3
    })())

Yeah and both of those are less readable, and used everywhere add up to a really crap code base relative to the same code in plain JS.

Yah, pojs is so much nicer because when you mistype breed as bred you get to debug the issue at runtime for a while changing things that are irrelevant when TS could have told you immediately

I would absolutely reject a PR with the IIFE.

Actually this cast is safe in TypeScript, additional variables are unnecessary.

The statement ‘const d: Dog’ and the expression ‘d as Dog’ are equivalent w.r.t. type safety. The compiler will error in both cases the if the value is not a Dog.

This is not correct. Following example is valid in strict TypeScript:

  interface Dog {
    breed: string;
  }
  const dog = {} as Dog;
  console.log(dog.breed);

Using `as` is very unsafe in TypeScript.

I've collected more quirks of `as` in this playground: https://www.typescriptlang.org/play/index.html#code/PTAEAMEs...

The article is just describing quirks, not arguing against them. Specifically for the first example they said "I think that the TypeScript stance here isn’t wrong".

Casting is as bad as using "any". You can make the compiler think anything you throw at it as that type and you can get bitten at runtime.

Thats not 100% true in TypeScript. TypeScript actually only allows "up-casts" and "down-cast" (but if the type is neither a supertype nor a subtype the compiler will throw an error).

That’s my understanding too. You just can’t cast types wily Nily.

Ya, I often have to write “this as any as T” because I’m using T as a self type.

Nope. This is not how casting works in TypeScript. To get an unsafe cast you have to go via the ‘any’ or ‘unknown’ types.

e.g.

‘foo as unknown as Dog’

There are a few casts that are allowed that I would consider unsafe, particularly around unions of literals or using empty object literals:

  // No error here
  type Animal = 'dog' | 'cat';
  const notAnimal = 'couch' as Animal;

  // No error here either
  type Food = { isSpicy: boolean };
  const empty = {} as Food;

https://www.typescriptlang.org/play/index.html#code/C4TwDgpg...

Casting may hide errors and is unnecessary in this case: `as const` will work just as well.

The correct use is to remove the `age` property in this case: if you're not keeping a reference to the object or that property and the called function cannot use it, why have it in the first place?

That’s not always true. If you are going to print the object to the console or send it in a network request it’s possible that the additional property is important.

But then it should be in the type signature of the object. TypeScript is signalling this as an error because it's a literal passed directly to the function and that property (theoretically) can never be used because it wasn't declared.

Why would casting hide errors?

In the simple case, if it could be Dog|Cat and you cast as Dog but you get a Cat, and TS could have told you about the error if it hadn't been forced to treat it as Dog. This can be fixed by having your types be derived by runtime validation.

Reply on news.ycombinator.com