=== relates to: S899

=== supercedes: S1154

=== on 24 Nov 2014, 12:57:37 Nicolas Peru wrote:
This rule seems ok to me but the message is not convincing me. I would go for something more explicit about the fact that the return value of the method is ignored.

"Return value of method 'xxx' is not used" 

=== on 1 Dec 2014, 09:31:20 Freddy Mallet wrote:
And we should be careful to not mix this rule with RSPEC-899:

* RSPEC-899 is about ignoring the result of a function call when this result indicates the status of the operation: KO, OK (so when exceptions are not used to trigger issues)
* This one RSPEC-2201, is about ignoring the result of a function call when this result contains the output of the operation 

=== on 27 Mar 2015, 13:36:47 Ann Campbell wrote:
Per discussion, I floated closing RSPEC-899 to C-Family team & met with objections.

=== on 10 Jan 2016, 12:46:52 Freddy Mallet wrote:
Hi [~ann.campbell.2], I don't understand why this rule is not part of "Sonar way" quality profile because for sure when an issue is raised this is bug. 

=== on 11 Jan 2016, 18:15:09 Ann Campbell wrote:
As I recall [~freddy.mallet], it's a question of confidence in accurately identifying methods without side effects.

=== on 13 Jan 2016, 09:26:38 Freddy Mallet wrote:
I know [~ann.campbell.2], but for instance in Java we've tuned the rule to be sure at 100% that we're not generating any false-positives (by limiting the scope to calls to immutable objects) and I think we must do the same thing for the other targeted languages. So at least in Java, this rule must be activated by default (cc [~nicolas.peru]).

=== on 13 Jan 2016, 13:33:55 Ann Campbell wrote:
Done [~freddy.mallet]

=== on 21 Feb 2020, 14:59:38 James Bromwell wrote:
I created https://github.com/SonarSource/SonarJS/issues/1948[a new issue on the SonarJS GitHub tracker] but I'm not sure if the fault is in the rule itself or in the JS/TS implementation of the rule, so I thought it might be worth bringing up here.