Meta-issue: Different type assertion behaviors

[RyanCavanaugh]

This is a disambiguator issue for tracking various type assertion-like constructs that have been requested

"is" type assertion

Tracking at #7481

Description: A type assertion operator that doesn't perform downcasting. This comes up reasonably often and is especially useful when you want to write an expression where the expression's target type is any/unknown but you know what type the expression ought to have.

// We want to validate that the object literal here is a Point3D,
// but the downcast here doesn't catch our miss of "z"
writeFile("point.json", JSON.stringify({ x: 2, y: 5 } _as_ Point3D);

This is also useful when writing function expressions or objects containing function expressions - its parameters can get contextually typed by the asserted-to type, but you really don't want downcasting of the return types to occur here.

#16605 tracks a different proposal for allowing a downcasting that downcasts the existence of missing properties but does not allow downcasting of types -- this is sort of ill-defined IMHO and needs some justification to exist as a separate entity.

"pass-through" type assertion

Tracking at #26045

Description: You currently have to choose between index signature validation at the initialization site or getting type checking on property existence:

type Neat = { [key: string]: boolean };

const x: Neat = {
    m: true,
    n: 10 // Want error here...
};
// ... and here
console.log(x.z);

The idea is some kind of annotation that still allows for inference, but doesn't change the type of the expression

Others

There are more to be found

[RyanCavanaugh]

TODO describe #10421

[RyanCavanaugh]

#26272 describes another use case for a "pass-through" assertion (simplified):

const a: Partial<Point> = { x: 10 };
// Error, 'x' might be undefined
console.log(a.x.toFixed());

Here we want to validate the initializer of a but not lose type information about which properties were initialized

[agentcooper]

I'm finding the following behavior confusing:

type Fruit = "apple" | "banana"
([1, 2, 3] as Array<[Fruit]>); // OK: error is expected
(["apple", "potato"] as Array<Fruit>); // Not OK: no error

Plaground.

Should this considered as a bug?