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.
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.
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)
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âŠ
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.