From f9ffca9670852658392442fdf3f6678b2f7b67cc Mon Sep 17 00:00:00 2001 From: Aaron Weiss Date: Tue, 16 Jan 2024 10:40:00 -0800 Subject: [PATCH] change to return greatest common subset of keys to correspond with index operation --- docs/keyof-type-operator.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/docs/keyof-type-operator.md b/docs/keyof-type-operator.md index 27ac818..2cdfceb 100644 --- a/docs/keyof-type-operator.md +++ b/docs/keyof-type-operator.md @@ -93,13 +93,11 @@ The remaining bit of complexity is the question of what to do for types that do not necessarily have one consistent set of keys. For instance, if you consider the type `{ x: number, y: number } | { a: number, y: number }`, you might wonder what you would get out of `keyof`. One reasonable answer is `"y"` since that is -the least common subset of keys present in the components of the union. Another -reasonable, albeit more conservative, answer is to simply say that the operator -fails to resolve in this situation. This RFC proposes, admittedly somewhat -arbitrarily, that we take the conservative stance of failing to resolve since it -is easier to permit more behavior later than to rule out more later. That being -said, one of the main points of interest in discussion of this feature is if -there are any immediate use-cases for this. +the greatest common subset of keys present in the components of the union. +Another reasonable, albeit more conservative, answer is to simply say that the +operator fails to resolve in this situation. This RFC proposes that we return +the greatest common subset of keys since this corresponds to the set of keys +that are allowed by indexing operations on tables of that type. ## Drawbacks @@ -110,7 +108,7 @@ the new type inference engine for Luau, and as such, there is little remaining drawback to implementing this. In fact, the implementation is already all done in the new type inference engine and amounts to less than 200 lines of code including comments. So, beyond looking for motivating examples for potentially -computing the least common subset of keys for unions of tables and the small +computing the greatest common subset of keys for unions of tables and the small amount of work that implementing that might entail, the author of this RFC hopes that this effort is simply an easy win for OOP in Luau supported by the technical credit built up by implementing the new type inference engine. @@ -123,6 +121,6 @@ order to keep things simpler, but both have corresponding operations in the language, and seem useful, and almost all of the work to implement them is shared. So, doing less here doesn't really save us anything. The other alternative is surrounding the choice of what to do when the set of keys are not -identical across unions of tables. The proposal here was to fail to reduce, and -thus to produce a type error, but the alternative of providing the least common -subset seems perfectly reasonable as well. +identical across unions of tables. The proposal here was to provide the greatest +common subset of keys, but the alternative of failing to reduce and thus +producing a type error seems perfectly reasonable as well.