-
Notifications
You must be signed in to change notification settings - Fork 73
[RFC] Amend Global Type Functions to Accomodate Read & Write Keys #165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[RFC] Amend Global Type Functions to Accomodate Read & Write Keys #165
Conversation
| Do not support table-like types with differing read and write types; including, but not limited to | ||
| [read-only properties](https://rfcs.luau.org/property-readonly.html). This RFC proposes adding an optional trailing | ||
| argument, a string literal type, to each. The current type expression `keyof<TableLike>` will become equivalent to the | ||
| expression `keyof<TableLike, "read"> | keyof<TableLike, "write">`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you just do composition? keyof<readonly<T>> and keyof<writeonly<T>> where readonly removes the write modifier, and conversely writeonly with read modifier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would that work with extern types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generic type functions sound like the better option here. I don't think there should be any support for extern types since trying to normalize them seems impossible, e.g. readonly<vector> would have to resolve to something wacky like vector & ~{write x: number, write y: number, write z: number} to work. If someone really needs that then they can just use UDTFs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it isn't unrealistic to normalize the read/write access of extern types, it is unrealistic to normalize the extern types themselves. That's what I'm addressing.
Additionally, there are many examples of the dissonance between extern types and table types being harmful to ease-of-use, as well as the development of the language. I think if it can be avoided, you shouldn't need to use a UDTF to get the read/write keys of an extern type. That's a very reasonable use-case for keyof IMO.
| type Meow = { | ||
| read purr: true, | ||
| } | ||
| -- Write Key 'purr' does not exist in type | ||
| type Mrrp = index<Meow, "purr", "write"> | ||
| -- 'true' | ||
| type Mrrp = index<Meow, "purr", "read"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type T = index<{ write p: number }, "p">Ugh, index<{ write p: number }, "p"> getting normalized to number is without doubt a bug. index and rawget are intended to only work on the read part!
|
This is actually a bug report, not an RFC, I think. The type system generates types like |
This is definitely an RFC. Getting |
|
The particular part Alex was commenting on, that |
|
👍 yeap! i just wanted to clarify that it was a real feature request since there's some overlap with a currently weird part of the type system. thanks :3 |
Rendered.