TypeScript add types for set methods proposal

Fixes #57228.

Set methods are stage 3, and I expect to ask for stage 4 in April.

I've used the simplest possible types here, but in some sense these are too restrictive. It's perfectly reasonable to ask if a Set of 0 | 1 is a subset of a Set of number, for example, or even of a Set of 1 | 2 - anything where the intersection of the types is nonempty (I guess that would be, any type S such that T & S extends never is false).

Unfortunately I don't know of a good way to express that constraint, at least not without making the types way more complex. So I've stuck with the simple thing here. But if someone has a suggestion for better types I'd happily take it.

One possibility would be to have the Set-producing types take SetLike<T> but the predicates take SetLike<unknown>. I don't know if that would be better.

Do note that this this PR introduces the SetLike interface.

Jan 30 '24 06:01 bakkot

I guess that would be, any type S such that T & S extends never is false

I think this concept of "overlaps with" or its opposite "is disjoint with" is actually useful quite often. For example, it would be the ideal type of the parameter in [].includes(...). Currently I use this utility:

export const includes = <array extends readonly unknown[], element>(
	array: array,
	element: element & array[number] extends never ? array[number] : element
): element is element & array[number] => array.includes(element)

declare const array: string[]
declare const overlapping: string | number
declare const nonOverlapping: boolean | number

// okay
includes(array, overlapping)

// error
includes(array, nonOverlapping)

I wonder if the team would consider adding a builtin Overlaps type for cases like these and the set methods in this PR.

Jan 30 '24 13:01 ssalbdivad

Unfortunately I don't know of a good way to express that constraint, at least not without making the types way more complex. So I've stuck with the simple thing here. But if someone has a suggestion for better types I'd happily take it.

I'm not sure there's a good solution for this right now - it's more or less the same problem as #48247/#26255 and the fix is generally considered to be #14520 (lower-bounded type parameters)--though FWIW I think an "overlaps with" constraint would be more useful for this than "supertype of"

Jan 30 '24 19:01 fatcerberus

@fatcerberus I definitely agree overlaps would be very useful in a number of circumstances like includes, as well as internally for a lot of these comparison errors that incorrectly assert the lack of an overlap (when really they're just checking for a downcast):

declare const a: { a: true }

declare const b: { b: true }

// '{ a: true; }' and '{ b: true; }' have no overlap
if (a === b) {
}

Jan 30 '24 21:01 ssalbdivad

Well, in reality any overlaps primitive we got would likely use the same internal check that produces the "these types don't overlap" error, so I don't think it would fix that problem by itself :wink:

Jan 31 '24 05:01 fatcerberus

@fatcerberus Maybe it would be an opportunity to revisit that logic if it were to be published as its own utility 😅

Jan 31 '24 15:01 ssalbdivad

@typescript-bot pack this @typescript-bot test this @typescript-bot test top200 @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this

Jan 31 '24 20:01 DanielRosenwasser

Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at d9efe9618eab17785c35964dd44f0699ac01c5f7. You can monitor the build here.

Update: The results are in!

Jan 31 '24 20:01 typescript-bot

Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite on this PR at d9efe9618eab17785c35964dd44f0699ac01c5f7. You can monitor the build here.

Update: The results are in!

Jan 31 '24 20:01 typescript-bot

Heya @DanielRosenwasser, I've started to run the diff-based user code test suite on this PR at d9efe9618eab17785c35964dd44f0699ac01c5f7. You can monitor the build here.

Update: The results are in!

Jan 31 '24 20:01 typescript-bot

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at d9efe9618eab17785c35964dd44f0699ac01c5f7. You can monitor the build here.

Jan 31 '24 20:01 typescript-bot

Heya @DanielRosenwasser, I've started to run the regular perf test suite on this PR at d9efe9618eab17785c35964dd44f0699ac01c5f7. You can monitor the build here.

Update: The results are in!

Jan 31 '24 20:01 typescript-bot

Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/159718/artifacts?artifactName=tgz&fileId=2BD1440F52B0CE1DB5E5082986F8EE22B10337C65AD4EDD247C29E5340509AFF02&fileName=/typescript-5.4.0-insiders.20240131.tgz"
    }
}

and then running npm install.

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

Jan 31 '24 20:01 typescript-bot

The "overlaps" concept is what we internally call "comparability". The problem with expressing it as an intersection that produces never is that it is rarely possible to say an intersection of two object types is vacuous.

In other words, you can't say that { meow(): void } & { woof(): void } is an impossible type to fulfill, so there is no straightforward way to disallow catSet.intersection(dogSet).

Jan 31 '24 20:01 DanielRosenwasser

@DanielRosenwasser Here are the results of running the user test suite comparing main and refs/pull/57230/merge:

There were infrastructure failures potentially unrelated to your change:

1 instance of "Package install failed"

Otherwise...

Something interesting changed - please have a look.

Details

puppeteer

packages/browsers/test/src/tsconfig.json

[MISSING] error TS2307: Cannot find module '@pptr/testserver' or its corresponding type declarations.
- packages/browsers/test/src/utils.ts#L13 in packages/browsers/test/src/tsconfig.json

Jan 31 '24 20:01 typescript-bot

Hey @DanielRosenwasser, the results of running the DT tests are ready. Everything looks the same! You can check the log here.

Jan 31 '24 20:01 typescript-bot

@DanielRosenwasser The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Angular - node (v18.15.0, x64)}
_{Memory used}	_{295,662k (± 0.01%)}	_{295,671k (± 0.01%)}	_~	_295,637k	_295,725k	_{p=0.810 n=6}
_{Parse Time}	_{2.66s (± 0.31%)}	_{2.67s (± 0.19%)}	_{+0.01s (+ 0.38%)}	_2.66s	_2.67s	_{p=0.050 n=6}
_{Bind Time}	_{0.83s (± 1.52%)}	_{0.82s (± 0.63%)}	_~	_0.82s	_0.83s	_{p=0.418 n=6}
_{Check Time}	_{8.19s (± 0.47%)}	_{8.21s (± 0.34%)}	_~	_8.18s	_8.26s	_{p=0.870 n=6}
_{Emit Time}	_{7.10s (± 0.25%)}	_{7.10s (± 0.23%)}	_~	_7.08s	_7.12s	_{p=1.000 n=6}
_{Total Time}	_{18.78s (± 0.30%)}	_{18.80s (± 0.15%)}	_~	_18.78s	_18.86s	_{p=1.000 n=6}
_{Compiler-Unions - node (v18.15.0, x64)}
_{Memory used}	_{193,514k (± 1.59%)}	_{192,944k (± 1.25%)}	_~	_191,491k	_197,365k	_{p=0.689 n=6}
_{Parse Time}	_{1.35s (± 0.87%)}	_{1.36s (± 1.76%)}	_~	_1.32s	_1.38s	_{p=0.220 n=6}
_{Bind Time}	_{0.72s (± 0.00%)}	_{0.72s (± 0.00%)}	_~	_0.72s	_0.72s	_{p=1.000 n=6}
_{Check Time}	_{9.38s (± 0.50%)}	_{9.41s (± 0.37%)}	_~	_9.36s	_9.44s	_{p=0.469 n=6}
_{Emit Time}	_{2.62s (± 0.66%)}	_{2.61s (± 1.40%)}	_~	_2.55s	_2.66s	_{p=0.570 n=6}
_{Total Time}	_{14.08s (± 0.38%)}	_{14.10s (± 0.37%)}	_~	_14.00s	_14.14s	_{p=0.332 n=6}
_{Monaco - node (v18.15.0, x64)}
_{Memory used}	_{347,460k (± 0.00%)}	_{347,465k (± 0.00%)}	_~	_347,442k	_347,478k	_{p=0.336 n=6}
_{Parse Time}	_{2.48s (± 0.44%)}	_{2.48s (± 0.36%)}	_~	_2.47s	_2.49s	_{p=1.000 n=6}
_{Bind Time}	_{0.93s (± 0.68%)}	_{0.93s (± 0.44%)}	_~	_0.92s	_0.93s	_{p=0.673 n=6}
_{Check Time}	_{6.96s (± 0.56%)}	_{6.96s (± 0.55%)}	_~	_6.92s	_7.03s	_{p=1.000 n=6}
_{Emit Time}	_{4.07s (± 0.45%)}	_{4.06s (± 0.34%)}	_~	_4.04s	_4.08s	_{p=0.241 n=6}
_{Total Time}	_{14.44s (± 0.36%)}	_{14.43s (± 0.32%)}	_~	_14.38s	_14.50s	_{p=0.809 n=6}
_{TFS - node (v18.15.0, x64)}
_{Memory used}	_{302,858k (± 0.01%)}	_{302,858k (± 0.01%)}	_~	_302,832k	_302,894k	_{p=0.689 n=6}
_{Parse Time}	_{2.01s (± 0.86%)}	_{2.02s (± 0.68%)}	_~	_1.99s	_2.03s	_{p=0.934 n=6}
_{Bind Time}	_{1.01s (± 1.04%)}	_{1.00s (± 1.22%)}	_~	_0.99s	_1.02s	_{p=1.000 n=6}
_{Check Time}	_{6.33s (± 0.41%)}	_{6.34s (± 0.34%)}	_~	_6.31s	_6.37s	_{p=0.624 n=6}
_{Emit Time}	_{3.59s (± 0.45%)}	_{3.59s (± 0.42%)}	_~	_3.57s	_3.61s	_{p=1.000 n=6}
_{Total Time}	_{12.94s (± 0.21%)}	_{12.96s (± 0.19%)}	_~	_12.92s	_12.98s	_{p=0.515 n=6}
_{material-ui - node (v18.15.0, x64)}
_{Memory used}	_{511,313k (± 0.00%)}	_{511,325k (± 0.01%)}	_~	_511,290k	_511,384k	_{p=0.748 n=6}
_{Parse Time}	_{2.65s (± 0.66%)}	_{2.65s (± 0.98%)}	_~	_2.62s	_2.68s	_{p=0.935 n=6}
_{Bind Time}	_{0.99s (± 1.04%)}	_{1.00s (± 0.98%)}	_~	_0.99s	_1.01s	_{p=0.203 n=6}
_{Check Time}	_{17.27s (± 0.37%)}	_{17.28s (± 0.40%)}	_~	_17.19s	_17.37s	_{p=0.936 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (± 0.00%)}	_~	_0.00s	_0.00s	_{p=1.000 n=6}
_{Total Time}	_{20.90s (± 0.26%)}	_{20.92s (± 0.33%)}	_~	_20.83s	_21.03s	_{p=0.685 n=6}
_{mui-docs - node (v18.15.0, x64)}
_{Memory used}	_{1,695,135k (± 0.00%)}	_{1,695,118k (± 0.00%)}	_~	_1,695,074k	_1,695,186k	_{p=0.199 n=6}
_{Parse Time}	_{6.53s (± 0.29%)}	_{6.52s (± 0.38%)}	_~	_6.49s	_6.56s	_{p=0.466 n=6}
_{Bind Time}	_{2.36s (± 0.22%)}	_{2.36s (± 0.35%)}	_~	_2.34s	_2.36s	_{p=0.114 n=6}
_{Check Time}	_{55.43s (± 0.37%)}	_{55.49s (± 0.33%)}	_~	_55.24s	_55.66s	_{p=0.687 n=6}
_{Emit Time}	_{0.16s (± 2.52%)}	_{0.16s (± 2.52%)}	_~	_0.16s	_0.17s	_{p=1.000 n=6}
_{Total Time}	_{64.48s (± 0.34%)}	_{64.53s (± 0.30%)}	_~	_64.26s	_64.71s	_{p=0.810 n=6}
_{self-build-src - node (v18.15.0, x64)}
_{Memory used}	_{2,410,763k (± 0.04%)}	_{2,410,667k (± 0.03%)}	_~	_2,409,469k	_2,411,451k	_{p=1.000 n=6}
_{Parse Time}	_{4.93s (± 0.99%)}	_{4.94s (± 0.59%)}	_~	_4.89s	_4.98s	_{p=0.575 n=6}
_{Bind Time}	_{1.88s (± 0.27%)}	_{1.88s (± 1.08%)}	_~	_1.87s	_1.92s	_{p=0.277 n=6}
_{Check Time}	_{33.45s (± 0.23%)}	_{33.46s (± 0.35%)}	_~	_33.26s	_33.58s	_{p=0.810 n=6}
_{Emit Time}	_{2.69s (± 1.90%)}	_{2.70s (± 1.91%)}	_~	_2.64s	_2.78s	_{p=0.810 n=6}
_{Total Time}	_{42.98s (± 0.17%)}	_{42.99s (± 0.30%)}	_~	_42.76s	_43.15s	_{p=0.335 n=6}
_{self-compiler - node (v18.15.0, x64)}
_{Memory used}	_{418,598k (± 0.00%)}	_{418,659k (± 0.02%)}	_~	_418,588k	_418,780k	_{p=0.230 n=6}
_{Parse Time}	_{2.79s (± 2.23%)}	_{2.74s (± 3.78%)}	_~	_2.66s	_2.87s	_{p=0.569 n=6}
_{Bind Time}	_{1.10s (± 5.44%)}	_{1.17s (± 6.50%)}	_~	_1.07s	_1.23s	_{p=0.112 n=6}
_{Check Time}	_{15.10s (± 0.36%)}	_{15.10s (± 0.34%)}	_~	_15.03s	_15.16s	_{p=1.000 n=6}
_{Emit Time}	_{1.14s (± 1.11%)}	_{1.14s (± 1.29%)}	_~	_1.12s	_1.16s	_{p=0.869 n=6}
_{Total Time}	_{20.13s (± 0.27%)}	_{20.15s (± 0.34%)}	_~	_20.07s	_20.24s	_{p=0.575 n=6}
_{vscode - node (v18.15.0, x64)}
_{Memory used}	_{2,811,213k (± 0.00%)}	_{2,811,228k (± 0.00%)}	_~	_2,811,192k	_2,811,278k	_{p=0.748 n=6}
_{Parse Time}	_{10.62s (± 0.38%)}	_{10.61s (± 0.37%)}	_~	_10.56s	_10.65s	_{p=0.808 n=6}
_{Bind Time}	_{3.42s (± 0.55%)}	_{3.41s (± 1.15%)}	_~	_3.39s	_3.49s	_{p=0.413 n=6}
_{Check Time}	_{59.81s (± 0.67%)}	_{60.09s (± 0.57%)}	_~	_59.62s	_60.54s	_{p=0.378 n=6}
_{Emit Time}	_{16.14s (± 0.57%)}	_{16.16s (± 0.62%)}	_~	_16.00s	_16.29s	_{p=0.628 n=6}
_{Total Time}	_{89.99s (± 0.38%)}	_{90.27s (± 0.43%)}	_~	_89.72s	_90.75s	_{p=0.230 n=6}
_{webpack - node (v18.15.0, x64)}
_{Memory used}	_{393,456k (± 0.01%)}	_{393,471k (± 0.02%)}	_~	_393,354k	_393,639k	_{p=0.936 n=6}
_{Parse Time}	_{3.08s (± 0.65%)}	_{3.07s (± 0.74%)}	_~	_3.04s	_3.11s	_{p=0.492 n=6}
_{Bind Time}	_{1.41s (± 0.39%)}	_{1.39s (± 1.33%)}	_~	_1.37s	_1.41s	_{p=0.341 n=6}
_{Check Time}	_{14.00s (± 0.30%)}	_{14.03s (± 0.34%)}	_~	_13.94s	_14.06s	_{p=0.171 n=6}
_{Emit Time}	_{0.00s (± 0.00%)}	_{0.00s (±244.70%)}	_~	_0.00s	_0.01s	_{p=0.405 n=6}
_{Total Time}	_{18.48s (± 0.21%)}	_{18.49s (± 0.20%)}	_~	_18.43s	_18.52s	_{p=0.627 n=6}
_{xstate - node (v18.15.0, x64)}
_{Memory used}	_{513,374k (± 0.01%)}	_{513,407k (± 0.00%)}	_~	_513,381k	_513,432k	_{p=0.065 n=6}
_{Parse Time}	_{3.27s (± 0.36%)}	_{3.28s (± 0.30%)}	_~	_3.27s	_3.29s	_{p=0.314 n=6}
_{Bind Time}	_{1.54s (± 0.49%)}	_{1.54s (± 0.49%)}	_~	_1.53s	_1.55s	_{p=1.000 n=6}
_{Check Time}	_{2.84s (± 0.87%)}	_{2.85s (± 0.91%)}	_~	_2.81s	_2.88s	_{p=0.685 n=6}
_{Emit Time}	_{0.08s (± 4.99%)}	_{0.08s (± 0.00%)}	_~	_0.08s	_0.08s	_{p=0.405 n=6}
_{Total Time}	_{7.73s (± 0.29%)}	_{7.74s (± 0.47%)}	_~	_7.70s	_7.79s	_{p=0.518 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Angular - node (v18.15.0, x64)
Compiler-Unions - node (v18.15.0, x64)
Monaco - node (v18.15.0, x64)
TFS - node (v18.15.0, x64)
material-ui - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

tsserver

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-UnionsTSServer - node (v18.15.0, x64)}
_{Req 1 - updateOpen}	_{2,345ms (± 0.43%)}	_{2,342ms (± 0.75%)}	_~	_2,330ms	_2,377ms	_{p=0.227 n=6}
_{Req 2 - geterr}	_{5,546ms (± 1.36%)}	_{5,548ms (± 1.54%)}	_~	_5,419ms	_5,620ms	_{p=0.936 n=6}
_{Req 3 - references}	_{323ms (± 0.30%)}	_{325ms (± 1.56%)}	_~	_321ms	_332ms	_{p=0.742 n=6}
_{Req 4 - navto}	_{274ms (± 1.45%)}	_{275ms (± 1.32%)}	_~	_271ms	_279ms	_{p=1.000 n=6}
_{Req 5 - completionInfo count}	_{1,356 (± 0.00%)}	_{1,356 (± 0.00%)}	_~	_1,356	_1,356	_{p=1.000 n=6}
_{Req 5 - completionInfo}	_{87ms (± 8.43%)}	_{90ms (± 7.40%)}	_~	_84ms	_101ms	_{p=0.466 n=6}
_{CompilerTSServer - node (v18.15.0, x64)}
_{Req 1 - updateOpen}	_{2,479ms (± 1.56%)}	_{2,483ms (± 1.23%)}	_~	_2,448ms	_2,535ms	_{p=0.689 n=6}
_{Req 2 - geterr}	_{4,197ms (± 2.07%)}	_{4,181ms (± 1.78%)}	_~	_4,123ms	_4,279ms	_{p=0.630 n=6}
_{Req 3 - references}	_{336ms (± 1.77%)}	_{340ms (± 1.61%)}	_~	_331ms	_346ms	_{p=0.568 n=6}
_{Req 4 - navto}	_{284ms (± 0.53%)}	_{285ms (± 1.19%)}	_~	_281ms	_291ms	_{p=0.466 n=6}
_{Req 5 - completionInfo count}	_{1,518 (± 0.00%)}	_{1,518 (± 0.00%)}	_~	_1,518	_1,518	_{p=1.000 n=6}
_{Req 5 - completionInfo}	_{80ms (± 6.65%)}	_{85ms (± 8.23%)}	_~	_74ms	_90ms	_{p=0.106 n=6}
_{xstateTSServer - node (v18.15.0, x64)}
_{Req 1 - updateOpen}	_{2,598ms (± 0.57%)}	_{2,612ms (± 0.44%)}	_~	_2,594ms	_2,626ms	_{p=0.126 n=6}
_{Req 2 - geterr}	_{1,736ms (± 2.23%)}	_{1,731ms (± 2.70%)}	_~	_1,680ms	_1,783ms	_{p=1.000 n=6}
_{Req 3 - references}	_{116ms (± 9.63%)}	_{119ms (± 8.24%)}	_~	_107ms	_128ms	_{p=0.466 n=6}
_{Req 4 - navto}	_{370ms (± 0.41%)}	_{371ms (± 0.56%)}	_~	_369ms	_375ms	_{p=1.000 n=6}
_{Req 5 - completionInfo count}	_{2,078 (± 0.00%)}	_{2,078 (± 0.00%)}	_~	_2,078	_2,078	_{p=1.000 n=6}
_{Req 5 - completionInfo}	_{311ms (± 1.57%)}	_{311ms (± 2.40%)}	_~	_301ms	_319ms	_{p=0.873 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

CompilerTSServer - node (v18.15.0, x64)
Compiler-UnionsTSServer - node (v18.15.0, x64)
xstateTSServer - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

startup

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{tsc-startup - node (v18.15.0, x64)}
_{Execution time}	_{153.16ms (± 0.20%)}	_{152.79ms (± 0.18%)}	_{-0.37ms (- 0.24%)}	_151.87ms	_157.17ms	_{p=0.000 n=600}
_{tsserver-startup - node (v18.15.0, x64)}
_{Execution time}	_{229.03ms (± 0.16%)}	_{228.91ms (± 0.15%)}	_{-0.12ms (- 0.05%)}	_227.67ms	_232.49ms	_{p=0.000 n=600}
_{tsserverlibrary-startup - node (v18.15.0, x64)}
_{Execution time}	_{231.42ms (± 0.19%)}	_{231.30ms (± 0.18%)}	_{-0.12ms (- 0.05%)}	_229.33ms	_238.19ms	_{p=0.031 n=600}
_{typescript-startup - node (v18.15.0, x64)}
_{Execution time}	_{230.78ms (± 0.19%)}	_{230.77ms (± 0.18%)}	_~	_229.27ms	_236.83ms	_{p=0.987 n=600}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

tsc-startup - node (v18.15.0, x64)
tsserver-startup - node (v18.15.0, x64)
tsserverlibrary-startup - node (v18.15.0, x64)
typescript-startup - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

Jan 31 '24 20:01 typescript-bot

@DanielRosenwasser Here are the results of running the top-repos suite comparing main and refs/pull/57230/merge:

Everything looks good!

Jan 31 '24 22:01 typescript-bot

@DanielRosenwasser Yes, that is exactly the behavior I'd expect in a structural type system, with a result of Set<{meow(): void; woof(): void}>. The type could still give completions based on the base type which must be overlapped, but this kind of intersection is definitely sensible as illustrated by an alternate example like { poisonous: true } & { mammalian: true } for a set of platypuses and echidnas 😄

I'm often frustrated by TS overreaching based on a comparability check (e.g. https://github.com/microsoft/TypeScript/issues/44645), especially when the word "overlap" is used in the error message which has a specific meaning that does not match the criteria for the error.

Jan 31 '24 22:01 ssalbdivad

I brought this up in the design meeting, specifically focusing on

the types of union/intersection
the parameter container types.

The feedback for them was:

Methods like union and intersection should be generic and return a corresponding TypeScript type. union should return a Set<T | U>, and intersection should return a Set<T & U>.
Methods should not expect their arguments to be related to the underlying container type. This risks accidental invocations of intersection that are guaranteed to produce empty collections, but it has the benefit of allowing more symmetric operations.

In other words, both stringSet.intersection(stringOrBooleanSet) and stringOrBooleanSet.intersection(stringSet) are valid invocations of each other.

I'll note that I am personally the most opposed to this behavior, but I was the lone dissenter. 🙂
With respect to SetLike, @rbuckton raised the same points of ReadonlySet being overkill. I suggested ReadonlySetLike might make more sense. Nobody else had a strong opinion.

@bakkot, in this PR I'd suggest to just address the first two points, do whatever you feel is right for point 3, and we will bikeshed by the time we can bring this in for TypeScript 5.5.

Jan 31 '24 23:01 DanielRosenwasser

WFM, thanks for the feedback. I'll get that pushed up later today.

Any opinions on isSubsetOf and friends? If not I'll default to making them generic, following point 2, even though (because they return booleans) this doesn't let you constrain the output.

Jan 31 '24 23:01 bakkot

Any opinions on isSubsetOf and friends? If not I'll default to making them generic

I think the right thing for those is to take a Set<unknown> since the type parameter will never be observed.

Jan 31 '24 23:01 DanielRosenwasser

In other words, both stringSet.intersection(stringOrBooleanSet) and stringOrBooleanSet.intersection(stringSet) are valid invocations of each other.

This is generally what people expect of e.g. Array.prototype.includes as well, and I largely concur, but to my knowledge there's no way to allow that without also allowing stringSet.intersection(numberSet) (unless we get lower-bounded or comparability constraints), correct?

Feb 01 '24 06:02 fatcerberus

@DanielRosenwasser Done. Specifically:

union<U>(other: ReadonlySetLike<U>): Set<T | U>; // things in result are in either
intersection<U>(other: ReadonlySetLike<U>): Set<T & U>; // things in result are in both
difference<U>(other: ReadonlySetLike<U>): Set<T>; // things in result are in receiver
symmetricDifference<U>(other: ReadonlySetLike<U>): Set<T | U>; // things in result are in either

and then ReadonlySetLike<unknown> as the parameter for the three predicates.

Feb 01 '24 06:02 bakkot

@fatcerberus It's possible to validate as a function parameter with an approach like the one I mentioned in my original comment which could be leveraged here, but I assume that falls into the category of "too complex for builtin types."

Feb 01 '24 09:02 ssalbdivad

Hmm, I have mixed feelings about the name ReadonlySetLike. While I get it--it doesn't have any of the mutating methods--it'd be weird (and maybe a bit misleading, for people reading the code) if I actually wanted to make a mutable setlike and had to extend ReadonlySetLike to get there.

Also it doesn't seem completely analogous to ArrayLike since the methods are defined to return a full-fledged Set...

Feb 01 '24 17:02 fatcerberus

but to my knowledge there's no way to allow that without also allowing...

Correct. "This is why we need Comparable<T>!" got brought up multiple times in the discussion 🙂

Feb 01 '24 19:02 RyanCavanaugh

If we are seriously thinking about Comparable<T>, why not take the more conservative option first and then introduce Comparable?

Feb 01 '24 20:02 DanielRosenwasser

The conservative approach still fails basic desirable things like subtyping the output or a.intersect(b) === b.intersect(a)

Feb 01 '24 21:02 RyanCavanaugh

Hmm, I have mixed feelings about the name ReadonlySetLike. While I get it--it doesn't have any of the mutating methods--it'd be weird (and maybe a bit misleading, for people reading the code) if I actually wanted to make a mutable setlike and had to extend ReadonlySetLike to get there.

While I'm fine with both SetLike and ReadonlySetLike, there are other names we could consider as well. In C++, the requirements for a Container are quite similar (i.e., has a size, is iterable), so Container<T> is a possible option if there's a strong negative sentiment towards ReadonlySetLike.

Also it doesn't seem completely analogous to ArrayLike since the methods are defined to return a full-fledged Set...

These methods allocate and return a new Set no matter what object you pass as the argument so long as it has the minimum necessary API for the methods to succeed. In fact, ArrayLike and SetLike are nearly identical in their capabilities, but are tailored to their specific protocols. Both are minimal, read-only representations of their respective full implementations. ArrayLike has a read-only length, the ability to read a single element by index, and the ability to read all elements by index and length. While SetLike has a read-only size, the ability to test whether a single value is in its domain via has(), and the ability to read all elements via keys().

Feb 01 '24 21:02 rbuckton

Ah, I think I misinterpreted ReadonlySetLike as being the interface that provided the new methods, which I'm guessing now isn't actually the case - that's the part I was objecting to, since they always return a real Set. My objections may have been misplaced :)

Feb 01 '24 22:02 fatcerberus

TypeScript TypeScript copied to clipboard

add types for set methods proposal

puppeteer

packages/browsers/test/src/tsconfig.json

tsc

tsserver

startup

TypeScript
TypeScript copied to clipboard