Skip to content

Consistent Typechecking Mode #63639

Description

@p-98

🔍 Search Terms

exact types consistent

✅ Viability Checklist

⭐ Suggestion

A compiler setting, similar to "strict mode", maybe "consistent mode", that treats missing keys on an object either as type never (not existent) or of type unknown (arbitrary).
Just changing the behaviour would obviously be massively breaking, but I think there should be an option to prevent the following errors.

The design goals say the focus isn't on a sound or "provably" correct type system, but they state the type system is supposed to be consistent. And since I think the mistake in the motivating example is easy to make, there should be the option to prevent this.

📃 Motivating Example

const original: {k: number} = {k: 2}
const forgotten: {} = original
const wrong: {k?: string} = forgotten

// expect wrong.k to be a string or undefined, but it is a number instead!

When treating missing keys as having type none/being non-existent:

const original: {k: number} = {k: 2}
const forgotten: {} = original
// ^-- Error:
// Type '{ k: number; }' is not assignable to type '{}'.
//  Types of property 'k' are incompatible.
//    Type 'number' is not assignable to type 'never'.
const wrong: {k?: string} = forgotten

Or when treating missing keys as having an arbitrary type/having type unknown.

const original: {k: number} = {k: 2}
const forgotten: {} = original
const wrong: {k?: string} = forgotten
// ^-- Error:
// Type '{}' is not assignable to type '{ k?: string; }'.
//  Types of property 'k' are incompatible.
//    Type 'unknown' is not assignable to type 'string | undefined'.

💻 Use Cases

  1. What do you want to use this for?
    => Utility functions can be specified much more tight with this system. But generally, a stricter type system makes for more correct programs, especially when the mistake from the motivating example is so easy to make
  2. What shortcomings exist with current approaches?
    => Having an optional property of certain type on an object becomes meaningless - it could actually have a different type. The same problem arises with index signatures.
  3. What workarounds are you using in the meantime?
    => I know of none.

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already created

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions