Type-safe const assertions

[btoo]

Suggestion

🔍 Search Terms

type-safe const assertions

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

By allowing const assertions to accept a type, they can statically validate the type of the value during construction, thereby providing the benefit of both standard and const assertions at the same time:

• literalExpression as const Type
• <const Type>literalExpression

where literalExpression is the literal expression whose type is being derived and Type is the type against which the derived type is going to be checked for extends

📃 Motivating Example

type WeekDay = 'm' | 'tu' | 'w' | 'th' | 'f';
const mondayAndTuesday = ['m', 'tu'] as const WeekDay[]; // needs to not error
type ConstAssertion1 = typeof mondayAndTuesday extends WeekDay[] ? true : false; // true
type ConstAssertion2 = typeof mondayAndTuesday extends readonly ['m', 'tu'] ? true : false; // true
const mondayTuesdayAndSaturday = ['m', 'tu', 'sa'] as const WeekDay[]; // needs to error

This should also make it possible to allow autocomplete suggestions when literalExpression as const WeekDay[] is being written

💻 Use Cases

I often find myself having to choose between using a standard type assertion and using a const assertion. Both offer important capabilities for static analysis:

• Standard: Assert that the type of the value being constructed extends SomePreexistingType
  • e.g.

    type WeekDay = 'm' | 'tu' | 'w' | 'th' | 'f';
    'sa' as WeekDay; // correctly errors

• const: Prevent type-widening of the value being constructed
  • e.g.

    const weekDays = ['m', 'tu', 'w', 'th', 'f'] as const;
    weekDays.filter(weekDay => weekDay === 'sa'); // correctly errors

However, there isn't a way to have them both (at least not without a runtime assertion function, it seems)

[RyanCavanaugh]

Possible duplicate of #7481? I'm not sure what inferred type you want mondayAndTuesday to have

[btoo]

I'm not sure what inferred type you want mondayAndTuesday to have

const mondayAndTuesday = ['m', 'tu'] as const WeekDay[];
type MondayAndTuesday = typeof mondayAndTuesday // readonly ['m', 'tu']

Another example would be

import type { CSSProperties } from 'react';
const reusableStyle = { width: '100%' } as const CSSProperties;

where type-checking/autocomplete would be possible while the value { width: '100%' } is being written, as long as as const CSSProperties has already been appended.

Possible duplicate of #7481?

This looks pretty synonymous with my proposal! Though I think dropping the is would be more ergonomic and idiomatic

[RyanCavanaugh]

Yeah I think with 7481 it'd be ["m", "tu"] as const (syntax???) readonly Weekday[] which composes pretty well.

[btoo]

Why would readonly need to be included in ["m", "tu"] as const (syntax???) readonly Weekday[]? Shouldn't const take care of that transformation?

[RyanCavanaugh]

You're right, it'd work either way there