Failure of Object.entries to infer value type about typescript HOT 6 CLOSED

This is a surprising result. I'm not entirely sure about this but I think it stems from the fact that interfaces can be augmented. So there is no actual guarantee that the inferred type will stay the same with code changes.

Type literals can't be augmented so type literals have "inferable indexes". If you take a look at the function signature of Object.entries you might see this kind of type:

type ObjectEntries = {
    <T>(o: {
        [s: string]: T;
    } | ArrayLike<T>): [string, T][];
    (o: {}): [string, any][];
}

As we see here... T can only be inferred from an index signature. So since interface types don't have one... ye, the type is not inferred there.

from typescript.

Remember that interfaces types are ostensibly nominal, not structural. If you want structural typing, stick to type.

TypeDoc has a handy @interface tag that lets you document structural types as if they were interfaces, which is a nice middle-ground.

from typescript.

I might be misreading what you are saying but in the TS type system both interfaces and types are usually compared structurally. Nominal types can be achieved using classes with private properties.

from typescript.

@Andarist They're compared structurally but during compilation, references to interfaces are treated nominally (rather than the entire structure being inlined) until a comparison occurs. This is a big difference and has a lot of downstream effects (e.g. in mouseover tooltip behavior). There are also some rules regarding intersections that apply only to interfaces to keep their behavior consistent with nominal typing.

from typescript.

This is a combination of #15300 with #38520.

(Calling interfaces "nominally typed" is confusing at best, so let's desist from doing that.)

from typescript.

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

from typescript.