Compiler/IDE should warn when a function is invoked whose return value is not being used

This would help developers find problems where the expected behaviour is mutating, but the actual behaviour is to return a mutated object.

example:

mutableList.removeAt(0)
mutableList.subList(...) //should raise a flag because it's return value is not being used.

This would match the behaviour of other languages such as Swift.

2 Likes

Yes, we have a couple of issues about that in our tracker, see this one https://youtrack.jetbrains.com/issue/KT-18024 and its related issues.

I think it would be a great feature that would allow to catch many erroneous situations in code, though currently I can’t tell anything about when it will be implemented.

But I get this warnings and was about to write angry post of how annoying it is.
Well it was couple days ago, but warning definitely was there.
Maybe it was inspections though.

In Swift they have you use the underscore character for things you want to
ignore. It signals to the compiler that you’re aware but you don’t care.

Example:

doSomethingThatReturnsSomething()     // compiler warning

_ = doSomethingThatReturnsSomething()     // no compiler warning

In F# you can call ignore function on result you don’t need:

fooWithResult() |> ignore

There are many cases where the value of an expression (for example an if expression) is immaterial. At least for functions it would be useful to be able to annotate those whose return value should not be ignored (either because they have no side-effects, or because doing so is “unsafe”). I wouldn’t want to have to look for the return values of mutableList.add or mutableList.set.

1 Like

Indeed, the return value of mutableSet.add() - boolean true/false if item was added - is often irrelevant to me.
There are many places where I do not care about a return value (and other places where I do want to get the return value of same function).

This is a feature that would be helpful sometimes, but at other times it would be highly annoying - especially if we have to add ceremony all over the place for return values we don’t need
 (assignment to _ or ‘redirect’ to ignore etc)

1 Like

oh, just like checked exceptions, but the opposite :wink:

I agree entirely with what @pdvrieze and @Tim_van_der_Leeuw.1 have just said about this matter.

It would be very annoying having to deal with compiler warnings where you’d chosen to ignore a function’s return value unless (exceptionally) the author of the function felt it would be unsafe to ignore it and had marked it with a suitable annotation.

It would be particularly onerous in the case of Kotlin Native and C interop where an int return value (which is often used to indicate some error or abnormal condition) is routinely ignored by C programmers either because they ‘know’ an error won’t happen or don’t care if it does because the error would be harmless.

Another example of a function where it is dangerous to ignore the return-value would be the entity ‘save()’ function of Spring Data repositories, which potentially return a different instance instead of updating the instance in place.
This has caused bugs in my code when I was not yet aware of that
 :wink:

So I can definitely see the value of such a feature, if I can have control over it and don’t have to pollute my code with dummy assignments for every mutableSet.add(), and can deal in a practical way with every entity save() invocation where I do not actually use the returned instance anyway.