You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! I've been coding in both Rust and Luau a lot recently, and I've found that the must_use rust lint has been very convenient, and I believe having it in my Luau code would also be beneficial. It's basically the inverse of the pre-existing Luau lint UnbalancedAssignment, and the natural companion to the ImplicitReturn lint.
I've encountered this issue a good number of times, but the most frequent is when working with custom immutable datatypes. Here's a simplified example of where things go wrong:
The only way I can catch this is through misbehavior at runtime, and even then the error is almost always silent - expressing itself through failed later on assertions / a general notice that the state isn't updating.
There are a few standard library usage patterns that this lint would make very obnoxious - for example, assert and table.freeze are commonly used without ever engaging with their returned values. Ideally, there would be some way to filter out functions. Alternatively, it could just be opt-in, something you apply to specific functions as needed.
With the "read" field attribute on the horizon when the new type-checker is ready, I think more developers than ever will work with immutable datatypes, and more than ever will encounter issues like this - this lint could save many of them headaches. Thank you for reading!
The text was updated successfully, but these errors were encountered:
Hello! I've been coding in both Rust and Luau a lot recently, and I've found that the must_use rust lint has been very convenient, and I believe having it in my Luau code would also be beneficial. It's basically the inverse of the pre-existing Luau lint UnbalancedAssignment, and the natural companion to the ImplicitReturn lint.
I've encountered this issue a good number of times, but the most frequent is when working with custom immutable datatypes. Here's a simplified example of where things go wrong:
The only way I can catch this is through misbehavior at runtime, and even then the error is almost always silent - expressing itself through failed later on assertions / a general notice that the state isn't updating.
There are a few standard library usage patterns that this lint would make very obnoxious - for example,
assert
andtable.freeze
are commonly used without ever engaging with their returned values. Ideally, there would be some way to filter out functions. Alternatively, it could just be opt-in, something you apply to specific functions as needed.With the "read" field attribute on the horizon when the new type-checker is ready, I think more developers than ever will work with immutable datatypes, and more than ever will encounter issues like this - this lint could save many of them headaches. Thank you for reading!
The text was updated successfully, but these errors were encountered: