Unable to use rest on generic that has been narrowed to an object about typescript HOT 5 CLOSED

If you can write "some string".length then string has a length property, so a string is a { length: number } even though it's not an object with a length property. You can try to slice this some other way but it's not clear that it's more intuitive.

from typescript.

The error is correct; these narrowings are not equivalent. Knowing that T isn't string isn't sufficient proof that it's object. Consider something like this:

const fn1 = <T extends string | { toFixed(): string }>(v: T) => {
  if (typeof v === 'string') {
    return { text: v };
  }

  const { ...rest } = v;

  return { text: '???', ...rest };
};
fn1(42);

from typescript.

Right, so effectively this is me forgetting that this is "types on a dynamic runtime" rather than Go or Rust or whatever where it could only be those two types - my general thinking was it sufficient as I'd told TS its either "x or y" and then checked if it was "y" so the opposite branch should then be "x"...

I'm trying to think why that trips me up though - I feel like TS does behave like this elsewhere, but maybe I'm just misremembering some subtilties 🤔

(also I realised I've left out my truthy check which'd mean the whole "null is an object" thing in theory shouldn't be relevant - I'm pretty sure that doesn't matter for my simple example, but would for more real-world code)

from typescript.

actually maybe this is more about TS not having a difference between "pure data type object thing" and ... idk what to call the alternative - things with methods.? it's not that though but just i.e. in my head I'm thinking "this function takes a plain object with some properties", but you've shown TS actually checks for something slightly different meaning depending on your type something like a primitive could be considered valid for what looks like an object type, and then boom here we are...

from typescript.

That makes sense - it's that an "object" is different from "a value with properties", and that really TS's syntax describes the latter rather than the former (which makes sense because that's the underlying principle of duck typing, which is what JS is doing).

Happy for this to be closed, and thanks for working this through with me 🙂

from typescript.