`Result value must be used` check

Hello.

Quite often while working with ImmutableJS data structures and other immutable libraries people forget that values are immutable:

They can accidentally write:

obj.set('name', 'newName');

Instead of:

let newObj = obj.set('name', 'newName');

These errors are hard to discover and they are very annoying. I think that this problem can’t be solved by tslint, so I propose to add some sort of "you must use the result" check into the compiler. But right now I have no idea how I want it to be expressed in the language, so I create this issue mainly to start a discussion.

Rust lang, for example, solves a similar problem with #[must_use] annotation. This is not exact what we want, but it’s a good example and shows that the problem is quite common.

[nh2]

Here is another example of a refactoring error that this type of check would prevent:

Consider having an onclick handler:

const onMovementClick = (direction: "forward" | "backward") => () => { ... }

used like:

<div onClick={onMovementClick("forward") }>Forward</div>
<div onClick={onMovementClick("backward")}>Backward</div>

Now you refactor, adding some logging:

<div onClick={() => { log("forward");  onMovementClick("forward");  } }>Forward</div>
<div onClick={() => { log("backward"); onMovementClick("backward"); } }>Backward</div>

This refactor is wrong; your buttons now no longer have any effect and your web app is broken due to what’s logically a type error that TypeScript did not help prevent. The correct code has some added () function calls:

<div onClick={() => { log("forward");  onMovementClick("forward")();  } }>Forward</div>
<div onClick={() => { log("backward"); onMovementClick("backward")(); } }>Backward</div>

Here, one needed to call f(someArg)() instead of f(someArg); the latter returns a function that is then unused.

If TypeScript had the ability to warn on unused return values, like Haskell and Rust can do with -Wall, this mistake would be impossible to make.

[TimWolla]

After having been burnt by a library updating a method to be const/pure in a new major version, whereas it modified state previously: +1

Calling pure methods without using the return value almost certainly is a bug. So if the library author was able to indicate this in some standardized way (e.g. the nodiscard as suggested above), TypeScript might’ve been able to prevent this issue from happening to me.