P
I would say that readability is improved, at least from a certain point of view, can be subjective.The second form is more explicit and it has there its readability advantage, even if someone can say that code that does nothing useful is noise and there would be less readable, depends on the school you use to define what is readable.Just remembering that C# never forbade you to silently discard a result of a function call. Some languages only let you rule out the result explicitly, otherwise you have to use the result in an expression, including storing in a variable. Now C# lets you be explicit in the discard, but still accepts to be implied.And C# doesn't error or warning because it does not use a variable, so there is also no reason, and the specific case does not involve a variable that would be mandatory without the discard.Then a benefit is to be more explicit and become more readable.I've already discovered reading one https://stackoverflow.com/a/59401495/221800 that C# has no obligation to optimize this, but can, it cites Haskell who has the obligation to neither calculate. But note that this is not about discard, because it could do even without his presence since the result is not even used. But Haskell is a pure language, C# is not and this optimization would be more complicated, even more if done by https://pt.stackoverflow.com/q/146250/101 since it would be something that would require time to identify whether it can optimize or not, and this done in runtime can defeat the possible benefit it would bring. In C# the functions may have https://pt.stackoverflow.com/q/330341/101 , and an optimization of not performing the function because the result can be discarded can stop doing something internal that will affect other parts.In https://stackoverflow.com/a/55693941/221800 No one disputes that it is useless in this scenario. It would be the same as not using discard.But I will disagree at a small point. It may be so today, I don't know if it's official or not, if the language doesn't do any optimization that it wouldn't do without it. discard. There you have to think whether it is worth it or not. So I would follow the advice of Eric Lippert, use if you think the code will be more readable, not if it will be faster, unless it takes much of the performance and measures in the implementation of the moment if there is advantage or not, what is worth today may not be worth more in the past. I've seen a lot of things change without anyone warning, some for better and some for worse.The discard was not created for thisAnd also reading https://docs.microsoft.com/en-us/dotnet/csharp/discards?WT.mc_id=DOP-MVP-5002397#a-standalone-discard will become clearer that the utility is even where a variable would be necessary for some reason, not the example reported in the question here that the variable is not necessary.The documentation shows a situation that can make a difference if you are returning a https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-5.0&?WT.mc_id=DOP-MVP-5002397 , then it is a case that you cannot ignore the result without being explicit. But it's not your example.And the documentation also shows that it can be a problem because _ can be a valid variable name and there this function precedes the construction of specific language, even in the matter of compatibility. But you have to congratulate those who used this as a variable name.In fact the mechanism was created to improve this point with pattern matching, tuples (deconstruction) and even with the good and old output parameter out, it was not thought of for other situations, but it would make no sense to prohibit a "deconstruction" of a method that returns a simple value, so the syntax has allowed its use as a matter of parity with the rest.All this since C# 7. What C# 9 brought is parity to licking that he did not let use and was weird, even in lick makes even more sense, it has a situation where it could require a variable.Creating a variable and keeping an object alive in it without need has a bad consequence, but that may not be a problem, although the best would not have the variable, but the case is not a choice between having a variable or not. In the answers I read show cases that make a difference in other scenarios, which makes every sense.If you were buying:var objeto = FazerAlgoERetornarSeSucesso();
and did not use objeto nowhere, and_ = FazerAlgoERetornarSeSucesso();
The second is clearly better because it avoids accidental use of `object' in future maintenance (as discussed in chat :P), in addition, of course, to create a variable that reserves space in the stack and secure the returned object for longer, butFazerAlgoERetornarSeSucesso();
today, even internally. https://github.com/maniero/SOpt/blob/master/CSharp/Syntax/Underscore.cs .ConclusionThen I'm going to say that in this scenario, until someone proves the opposite that there is no advantage beyond the subjective legibility, there is no difference.There will be no less memory allocation, less pressure in the GC or even less battery reserve comparing the two cases because both there are no variables. What changed in C# 7 is that _ is no longer a variable, but if you used this symbol it was a variable with that name (since declared with a type or var) and without optimization it would need to be reserved. But the object that is returned nothing changes.
