Generic rest of intersection should be assignable to its type parameter constituents

[sandersn]

Search Terms

generic rest intersection type parameter

Suggestion

The rest of an intersection containing type parameters and object types should be assignable to the type parameters if the rest removed all the properties from the object types. For example:

function ripoff<T>(augmented: T & { a }): T {
  const { a, ...original } = augmented;
  return original;
}

This is technically not safe — the instantiation of the type parameters could overlap with the object types — but it is how higher-order spread currently behaves. I believe the most common use of rest is with disjoint types. (Spread is similar, but identical types is the most common use there.)

One way to allow this is to create a new assignability rule:

Pick<T & U & ... & { a } & { b } & ..., Exclude<keyof T & U & ..., 'a' | 'b' | ...>> ⟹ T & U & ...

In prose, the rule is that the pick of an intersection that consists of only type parameters and object types is assignable to the intersection of the type parameters if the second argument is an Exclude, and the Exclude's first argument is keyof the intersection of the type parameters, and the Exclude's second argument is the keys of the intersection of the object types.

Another optional is a simpler rule, where the pick of any intersection with a type parameter T is assignable to T:

Pick<T & ..., Exclude<keyof T & ..., K>> ⟹ T

Note that these rules don't cover what to do with constrained type parameters. The second rule is inaccurate enough already that it probably doesn't matter, but the first rule should probably have an additional restriction on Exclude's second argument.

Use Cases

React HOCs basically all do this.

Examples

From this comment:

import React, { Component } from 'react'

import { Counter } from './counter-render-prop'
import { Subtract } from '../types'

type ExtractFuncArguments<T> = T extends (...args: infer A) => any ? A : never;

// get props that Counter injects via children as a function
type InjectedProps = ExtractFuncArguments<Counter['props']['children']>[0];

// withCounter will enhance returned component by ExtendedProps
type ExtendedProps = { maxCount?: number };

// P is constrained to InjectedProps as we wanna make sure that wrapped component
// implements this props API
const withCounter = <P extends InjectedProps>(Cmp: React.ComponentType<P>) => {
  class WithCounter extends Component<
    // enhanced component will not include InjectedProps anymore as they are injected within render of this HoC and API surface is gonna be extended by ExtendedProps
    Subtract<P, InjectedProps> & ExtendedProps
  > {
    static displayName = `WithCounter(${Cmp.name})`;

    render() {
      const { maxCount, ...passThroughProps } = this.props;

      return (
       // we use Counter which has children as a function API for injecting props
        <Counter>
          {(injectedProps) =>
            maxCount && injectedProps.count >= maxCount ? (
              <p className="alert alert-danger">
                You've reached maximum count! GO HOME {maxCount}
              </p>
            ) : (
              // here cast to as P is needed otherwise compile error will occur
              <Cmp {...injectedProps as P} {...passThroughProps} />
            )
          }
        </Counter>
      );
    }
  }

  return WithCounter;
};

// CounterWannabe implement InjectedProps on it's props
class CounterWannabe extends Component<
  InjectedProps & { colorType?: 'primary' | 'secondary' | 'success' }
> {
  render() {
    const { count, inc, colorType } = this.props;

    const cssClass = `alert alert-${colorType}`;

    return (
      <div style={{ cursor: 'pointer' }} className={cssClass} onClick={inc}>
        {count}
      </div>
    );
  }
}

// if CounterWannabe would not implement InjectedProps this line would get compile error
const ExtendedComponent = withCounter(CounterWannabe);

Checklist

My suggestion meets these guidelines:

• This probably wouldn't be a breaking change in existing TypeScript/JavaScript code. Would need to be tested.
• 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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[weswigham]

While this is desirable for spreads specifically, I don't think we'd want to do this for intersections in conditionals in general, as it'd start allowing a bunch of unsound conditional type assignments (not just the object rest one). I also don't think any simplification rules relying on the exact conditional or mapped type used (Pick, Exclude) rather than the type constructors shape is particularly reliable.

[jack-williams]

How often are spread operations on objects like this used when constituents of the intersection are not disjoint? The disjoint case seems far more useful (to me).

Would it be possible to have a strict spread mode where spreading a value of type T & U implicitly asserts that T and U are disjoint. Then the type of the original can actually be given the type T in the spread, rather than the Pick + Exclude version.

EDIT: Disclaimer. I haven't really been following the generic spread stuff especially closely, so I apologise if I missed something obvious or previously covered.

[AlCalzone]

How often are spread operations on objects like this used when constituents of the intersection are not disjoint? The disjoint case seems far more useful (to me).

Real-world example: https://github.com/AlCalzone/ioBroker.tradfri/blob/master/src/main.ts#L548

const config: ioBroker.AdapterConfig = {
	...adapter.config,
	...newConfig,
};

where newConfig is effectively Partial<typeof adapter.config>. This is used to merge two objects, where the properties of the 2nd one have higher priority.

[jack-williams]

Related and/or solved by this.
#29062
#28884
#29000
#28938