Proposal: Add `must-use` to functions that have no purpose being called without handling the return

[WolfGangS]

An "error/smell" allot of linters track is Unused return variable, this is a little similar to pure, but not quite as it doesn't really care about undesirable side effects such as errors, more that the function has no purpose being called if you aren't making use of the returned value.

So adding a concept of must-use or intended-side-effect or similar, would allow for generation of this kind of linting spec.

For instance, llAcos is impure because it can cause an error, but it should probably be marked as must-use: true as there really is no reason to call it, if you don't want the resulting value.

Also useful for more aggressive optimization routines, as they can nix out calls that have no desirable side effect, and who's return values aren't being used.

Proposed addition

diff --git a/lsl_definitions.yaml b/lsl_definitions.yaml
index 96c50a0..c7008bf 100644
--- a/lsl_definitions.yaml
+++ b/lsl_definitions.yaml
@@ -4736,32 +4736,33 @@ events:
 functions:
 
 #  <key>: is the LSL name for the function.
 #    energy: Script energy consumed by the function. (When in doubt just use 10.0)
 #    sleep: Additional sleep time imposed by the script after this function completes.
 #    return: Return type of the function.
 #    arguments: An array of maps of maps describing the parameters to this function.
 #    tooltip: A brief description of this function. Map of maps is used to retain ordering.
 #    func-id: The LSO function identifier, (See comment at the top of this file.)
 #    private: Should this function be omitted from the generated documentation.
 #    deprecated: Has this function been deprecated.
 #    pure: Is the function guaranteed to have no side effects.
 #    native: If true, this function must use a native implementation for non-LSO VMs.
 #    god-mode: If true, this function can only be executed in god mode.
 #    experience: If true, this function requires an experience to be set for the script to compile.
 #    linden-experience: If true, this function requires a linden-owned experience.
+#    must-use: If true, this functions return value should be used, as there is no other reason to call the function
   llAbs:

If this is deemed desirable I'll make a PR with the changes.

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #24 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @WolfGangS (replace 20 with the amount, and @WolfGangS with the user to tip).

📖 If you want to learn more, check out our documentation.

[HaroldCindy]

Some kind of nodiscard makes sense to me! I'm assuming linters already support a nodiscard annotation? Also, should pure imply nodiscard?

[HaroldCindy]

Seems like it's still an open RFC? luau-lang/rfcs#83

[WolfGangS]

Its a feature already available in other linters, like selene.

Currently I generate my own list of functions for it, see https://slua.wlf.io/dist/sl_selene_defs.yml which is why must use was in my head.

And nodiscard is a better name for it I think too.

Besides slua though it'd be good information to have to help improve lsl linting too

[HaroldCindy]

Alright! If selene already supports mustuse let's just do that, must-use attr in YAML having pure imply must-use, and then you can use that to add a mustuse attr in your Luau type packs.

[WolfGangS]

I will make a pr, but just to make sure

If pure, don't include as must-use it's implied?

So a check would be something like

if  func.pure or func.["must-use"] then
    // functions return type shouldn't be discarded
end

[HaroldCindy]

Yep, anything that wants to add mustuse annotations in generated code can look at either func.pure or func.must_use as a signal that it'd be appropriate to add, so you shouldn't need to do anything special.

[WolfGangS]

While working through i found a few functions that "might" be pure (but aren't marked as such) depending on serverside implementation

• llLinear2sRGB
• llsRGB2Linear
• llList2ListSlice
• llList2ListStrided
• llListFindList
• llListFindListNext
• llListFindStrided
• llRound
• llSHA1String
• llSHA256String
• llSignRSA
• llVerifyRSA

All of those should be "doable" without external state, but that depends on implementation so I can't check

I will make the pr now, but those might need changing on review