Type Assertion after Creating a Variable

[mrjackyliang]

🔍 Search Terms

type assert after creating a variable

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

This is something I noticed when I was writing my Homebridge plugin:

// Create the new accessory without context.
const newAccessory = new this.#api.platformAccessory(
  device.name,
  device.hap.uuid,
  getAccessoryCategory(device.hap.category),
);

// Set the context into the new accessory.
newAccessory.context = device;

// Let TypeScript know that the context now exists. This creates additional runtime.
const typedAccessory = newAccessory as ADTPulsePlatformAddAccessoryTypedNewAccessory;

// Using the updated type constant.
this.#log.info(`Adding ${typedAccessory.context.name} (id: ${typedAccessory.context.id}, uuid: ${typedAccessory.context.hap.uuid}) accessory ...`);

The approach with this in the current TypeScript environment is valid, but I would like not to assign a new variable that creates additional runtime. At least I tried to search for something like this.

I can, however just set the type to the final type with the context, but that introduces an error when I started querying the context, which at that time was undefined.

📃 Motivating Example

I believe this fits into the goals of TypeScript because it helps create a more type-safe environment.

💻 Use Cases

1. What do you want to use this for?
   I'm using this in situations where I cannot account for types being assigned at a particular time.

2. What shortcomings exist with current approaches?
   I can either pre-define the type with a filled-in context type (which may cause runtime crashes), or create a new constant and type assert that (what I'm doing now).

3. What workarounds are you using in the meantime?
   Same as bullet point 2.

[fatcerberus]

I don’t know what you mean by “create additional runtime” but I gather it’s something to do with runtime type info which is out of scope for TS (type information is intentionally erased by the compiler and has no effect on runtime behavior), hence these two bullet points which you probably shouldn’t have checked:

* This could be implemented without emitting different JS based on the types of the expressions
* This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)

Disregard the above; I misread the issue.

[jcalz]

Looks like a duplicate of #10421

[mrjackyliang]

Oh sorry! This is a duplicate.