Add an `absent` type forbidding presence

[RobertSandiford]

Suggestion

🔍 Search Terms

type, absent, unset, none, missing, undeclared, not set, undefined

✅ 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.)
• [I think so?] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Add a type (working title absent) that forbids presence of the property or variable.

📃 Motivating Example

The absent type would allow forbidding presence of a property on an object, forbidding a property or method in a derived class, and would allow abstract properties that can be configured to be required or not through generics.

💻 Use Cases

Consider a front end, react-like-framework, using classes.

The absent type combined with a generic would allow toggling between using state, and enforcing type safety on that state (requires initialisation), or not using state, which forbids presence of state. (This is my use case and motivation for this change)

abstract class FrameworkComponent<State extends (object | absent) = absent>{
  abstract state: State
}

class StatelessAppComponent extends FrameworkComponent {
  // specifying state here would violate `absent` type, showing a type error
  render => () => 'Hi - I am a stateless component'
}

type StatefulAppComponentState = {
  message: string
}

class StatefulAppComponent extends FrameworkComponent<StatefulAppComponentState> {
  // omitting state here would violate the requirement of state: StatefulAppComponentState property
  state: StatefulAppComponentState = {
    message: 'Hi - I am a stateful component'
  }
  render => () => this.state.title
}

Here is an example from Next today. The state property is not typesafe, and this code produces a run time error, despite no type errors.

'use client'

import React from 'react'

type Props = object
type State = {
    a: number,
}   

export default class Component extends React.Component<Props, State> {
    render() {
        this.state /// Readonly<State>
        console.log('state.a', this.state.a) // runtime error
        return <p>Component</p>
    }
}

To avoid this the framework would have to require state to be set in every component, with stateless components having to add state: undefined or state = undefined, or create a StatelessComponent variant. This is not the end of the world, it's a bit of an annoyance (seemingly enough of an annoyance that React has sacrificed type safety to avoid it).

export default class StatelessComponent extends React.Component {
    state: undefined
    render() {
        return <p>StatelessComponent </p>
    }
}

---

Consider a payment processing system, where we want to prevent double processing of orders

type OrderUnpaid = {
  price: number,
  paymentId: absent
}

type OrderPaid = {
  price: number,
  paymentId: string
}

function processPayment(order: OrderUnpaid): OrderPaid {
  return {
    ...order,
    paymentId: 'abcd1234'
  }
}

let order: OrderUnpaid = {
  price: 57
}

// assigning OrderPaid type to OrderUnpaid
order = processPayment(order) // type error, type 'OrderPaid' cannot be assigned to type 'OrderUnpaid', 'paymentId' must be absent in 'OrderUnpaid'

// accidental second payment processing
order = processPayment(order)

//or

const orderPaid = processPayment(order)

// accidental second payment processing
// passing OrderPaid type to function expecting OrderUnpaid
processPayment(orderPaid) // type error, type 'OrderPaid' does not satisfy the constraint 'OrderUnpaid', 'paymentId' must be absent in 'OrderUnpaid'

How this looks in TypeScript today

Playground

type OrderUnpaid = {
  price: number
}

type OrderPaid = {
  price: number,
  paymentId: string
}

function processPayment(order: OrderUnpaid): OrderPaid {
  return {
    ...order,
    paymentId: 'abcd1234'
  }
}

let order: OrderUnpaid = {
  price: 57
}

// assigning a wider object to an existing object is allowed
order = processPayment(order)

// accidental second payment processing
processPayment(order) // allowed, application bug

//or

const orderPaid = processPayment(order)

// accidental second payment processing
// passing a wider object to a function is allowed
processPayment(order) // allowed, application bug

An Order type with an option paymentId does not improve safety

type Order = {
  price: number
  paymentId?: string
}

undefined and ?: syntax

{ prop: undefined } requires prop to be present

{ prop?: 'foo' } allows prop to be absent, or set to undefined

This suggests some concept of absent already exists in TS.

Therefore, ?: T would equate to T | undefined | absent

absent variables

const foo: absent would probably not be allowed. const foo in javascript creates the variable, so this would be an oxymoron. This could be treated as a developers aid, being allowed, and emitting no javascript, but I don't see a use case, so its easier not to.

absent properties on the global/window object should I think prevent those variables being declared with var. I expect that this will very rarely be used, but it should really be enacted for consistency.

⇄ Relations to other issues

Exact types #12936 - this issue solves some of the same issues that Exact types could be used to solve. Especially in the second example. However in the first example it is serving a different role.

Exact types might rely on absent type, or might be user implementable using an absent type.

🛠️ Implementation challenges

I don't see anything super difficult. Unions and the like seem fine. Someone who knows more about TS internals can comment.

I'd be interested to hear how this type and concept would gel with existing code & infrastructure - whether it's something that would fit in naturally or not.

[Jamesernator]

{ prop?: 'foo' } allows prop to be absent, or set to undefined

There already exists exactOptionalPropertyTypes which does exactly the same thing, in that it doesn't allow prop?: 'foo' to include undefined.

The fact abstract doesn't work work with optional types as I mentioned honestly seems like a bug.

[MartinJohns]

IMO this approach just sounds like a hack. The much cleaner approach would be to use the undefined type (or a unique symbol). Check for values of properties, not presence of properties.

[RobertSandiford]

There already exists exactOptionalPropertyTypes

Interesting. It seems like a good move, but I am guessing that it is off in strict mode due to back compat issues. Do you know?

If you are suggesting that that flag provides the suggested feature, I am sure it doesn't.

It reduces the acceptable values of ?: T from T | undefined | absent to T | absent. It doesn't allow allow absent alone, and therefore can't be used with generics to narrow S extends (object | absent) = absent down to specific type.

With optional abstract properties you could do

abstract class Component<S extends object> {
  abstract state?: S
}

but this wouldn't require the derived class to actually set state. The problem is the same with or without exactOptionalPropertyTypes. Your state property would always be S | undefined, and every time you work with state, framework side or user side, you have to check whether its undefined in order to be typesafe. It's not worth doing, better just to typecast state to S, and hope that the user initialized it, so no real benefit there.

In order to narrow down from extends (object | absent) to an object or absent, there has to be an actual named concept of absent.

[MartinJohns]

Interesting. It seems like a good move, but I am guessing that it is off in strict mode due to back compat issues. Do you know?

It's not even enabled in strict mode by default, due to the large amount of issues it can cause.

[RobertSandiford]

IMO this approach just sounds like a hack. The much cleaner approach would be to use the undefined type (or a unique symbol). Check for values of properties, not presence of properties.

I don't see what this has to do with the suggestion. undefined and absent are different.

In the framework example, using undefined requires each component to implement state even if not using it, which is what I am trying to avoid.

In the second example you could do runtime checks on the values of properties, but you have no checking of your code and are relying on your own logic. With this suggestion typescript verifies the safety of your code, as opposed to needing to write, maintain and run automated tests to do the same checks.

The absence of a variable or property is an important part of the meta-data on an object. If we can only talk of what an object has, and not of what an object does not have, we are missing part of the picture in describing that object. Imagine trying to describe a person with a missing left leg, while only being able to say what he has and not what he does not have. You can only create a description of a person who has his other limbs, and may or may not have his left leg. This is our current description of objects, unless I am missing something very important.

[RyanCavanaugh]

There's a reason that some information goes on the property slot (optionality) and some goes on the type, and that there aren't any type modifiers which change information about the property slot.

Once you have absent, then a bunch of stuff stops making sense:

• What is absent | string, and how does that differentiate from just x?: string under EOPT?
• What is absent & string ? Is it really just never ?
• What happens if you have a parameter of type absent, especially in a non-trailing position?
• What does let x: absent mean?
• "No no no you just wouldn't write those things" - ok but you will have them appear in generic instantiation; for any T<U>, T<absent> now needs to have some specific meaning, meaning that anywhere a type can appear, you have to have some sensible answer about what the higher-order compositional effects of seeing an absent are.

I can understand why some scenarios seem to call for per-site exactOptionalPropertyTypes but you can read discussion on that flag to understand why it's generally better suited as a global setting.

[RobertSandiford]

@RyanCavanaugh

What is absent | string, and how does that differentiate from just x?: string under EOPT?

It's the same.

What is absent & string ? Is it really just never ?

Absolutely

What happens if you have a parameter of type absent, especially in a non-trailing position?

In a trailing position its the same as not being there (TS blocks additional args), unless that is configurable.
In other positions it would create invalid typings, or forced any subsequent optional not to be passed, should probably throw a compiler error or warning

What does let x: absent mean?

This was covered, probably it is prohibited, as oxymoronic

"No no no you just wouldn't write those things" - ok but you will have them appear in generic instantiation; for any T, T now needs to have some specific meaning, meaning that anywhere a type can appear, you have to have some sensible answer about what the higher-order compositional effects of seeing an absent are.

OK good point. I'll have a think about it

I can understand why some scenarios seem to call for per-site exactOptionalPropertyTypes but you can read discussion on that flag to understand why it's generally better suited as a global setting.

I don't see the connection to this suggestion. The suggestion is about prohibiting props, not making them optional. Especially for reducing a Generic down to one or the other and not leaving it optional.

[RyanCavanaugh]

I don't see the connection to this suggestion

Because under EOPT, your request is satisfied by

type OrderUnpaid = {
  price: number,
  paymentId?: never
}

type OrderPaid = {
  price: number,
  paymentId: string
}

[RobertSandiford]

@RyanCavanaugh

I see. But that doesn't cover the first use case (which is my use case). Because I can't switch between abstract state: S and abstract state?: never using generics. Hence bringing absent into the type space.

So perhaps the issue is how to bring the ?: concept into a Generic or conditional

Something like

abstract class C<(S extends (object | ?never))> {
    abstract state: S // extends-object or ?: never 
}

But maybe we are opening up new problems again.

[dead-claudia]

How does this differ from never?

[RobertSandiford]

How does this differ from never?

A property type never means that the property exists, but it will not return anything, even undefined, if accessed - for example it has a getter that will throw an error or exit the program.

absent simply means that the property does not exist.

See #55121