Hi @Mark_Jansen,
The recommendation is to isolate slicing in a dedicated function so that this single violation of the rule can be accepted on SonarQube or SonarCloud after a review.
I think that it is still worth raising a violation here, because the fact that the function only has return *this; doesn’t necessarily imply that the author intended slicing to happen here (they might have just used the wrong return type for example). The only way to ensure that intention is clear, is by doing a review, and accepting this single violation.
Thank you for sharing your feedback though, I will also check with the team to see if we want to revisit this decision…
You are right, the card I shared earlier describes a solution that we are currently working on, where you can silence an issue without adding product-specific attributes that may reduce code readability. Instead, the issue is accepted locally, and this is synchronized among all collaborators by leveraging connected mode.
If you are more interested in in-code issue suppression, you may find this discussion relevant. We are still having discussions about this subject, and we may provide a solution soon. Stay tuned!