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

"MustUse" lint for unused function return values #1611

Closed
nightcycle opened this issue Jan 10, 2025 · 1 comment
Closed

"MustUse" lint for unused function return values #1611

nightcycle opened this issue Jan 10, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@nightcycle
Copy link

nightcycle commented Jan 10, 2025

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:

type Item= {
	read Color: Color3
}
function setColor(item: Item, color: Color3): Item
	if item.Color:ToHex() == color:ToHex() then
		return item
	end
	local out = table.clone(item)
	out.Color = color
	table.freeze(out)
	return out
end

-- mistake
setColor(item, Color3.new(1,0,0)) -- I've forgotten item isn't mutable

-- correct usage
item = setColor(item, Color3.new(1,0,0))

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!

@nightcycle nightcycle added the enhancement New feature or request label Jan 10, 2025
@deviaze
Copy link

deviaze commented Jan 11, 2025

you're in luck as there's an rfc for this rn: luau-lang/rfcs#83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants