Skip to content
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

RFC: Support Generics in Metamethods #82

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AbcreatorDev
Copy link

RFC to support generic types in metamethods since it appears to not currently be supported. I am currently using the new type solver in Roblox Studio which is relevant as this RFC makes use of the 'index' type function for demonstration purposes and to accurately display use-cases.

Rendered

@AbcreatorDev AbcreatorDev changed the title Support Generics in Metamethods RFC: Support Generics in Metamethods Dec 1, 2024
@aatxe aatxe self-assigned this Dec 3, 2024
@aatxe
Copy link
Contributor

aatxe commented Dec 3, 2024

I think I'm sympathetic to the problem you're describing here, but it is hard to tell with how the RFC is written. It reads less like an RFC, and more like a confusingly-written bug report for the new type solver. I'll try to provide more detail below, but in general, this RFC leans way too much on just pasting code and imagining that the reader will know what you mean.

For any good bug report or any good RFC, you should be clearly describing in English both what the current behavior is ("typechecking doesn't work" is not a clear description because it does not say how it doesn't work, e.g. an unnecessary type error, the wrong type being inferred, something else, etc.) and what the desired behavior is ("typechecking works" is not a clear description for similar reasons, we should be clear about what that actually means). This means I'd expect the motivation to clearly convey (ideally with a simplified real example, not something totally contrived and artificial) what task you hope to accomplish, and why that is an important enough issue to motivate additions to the language. For the design of the feature itself, you want to clearly establish, again with both English and with clear code that helps illustrate the feature, rather than your intended use case for it. If necessary, it's okay to also use the example to motivate the problem further, but that along is not a sufficient design.

Overall, you should be describing problems and solutions that are general. An RFC is a living document that will describe the feature perpetually, so there's no place for comments like "Another reason why the above alternatives aren't feasible for my use-case is that I want to use this in some of my upcoming public modules and hence don't want to have a 'unique way' to set values just so that I can satisfy the typechecker." The language is not being designed around any one person's personal use case. Likewise, the comment "I'm aware that the keyof(typeof(foo))&K disables the auto-complete behaviour however it is very possible to work around that. I just wrote a very quick and simple code-sample to demonstrate what the ideal solution would be for the return typechecking." feels very out of place. You can read existing accepted RFCs in this repository to get a better idea of how an RFC should read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants