Re: RFC: Marking return values as important (#[\NoDiscard])

> Le 30 janv. 2025 à 16:51, Tim Düsterhus <tim@bastelstu.be> a écrit : > > Hi > > Am 2025-01-30 10:02, schrieb Rowan Tommins [IMSoP]: >> I think it would be good to explore alternatives - for instance, I think C# has a reserved >> _ variable to assign discarded results to, but may be misremembering. > > A quick search confirms that C# supports the _ variable. > It's also supported with Rust. > > We are open to possible alternatives to the (void) cast, this > was also something we discussed while drafting the RFC. However we opted for the > (void) with out proposal for the following reasons: > > - $_ = func(); is already working as a regular variable (see my > reply to Rob regarding lifetimes), thus repurposing it as a “discard pile” would cause backwards > compatibility issues. > - _ = func(); would introduce new syntax (just like > (void)), but does not look and feel like PHP to us. > - (void)func(); has precedent in other languages (just like > _ =) and looks and feels like PHP. In fact in earlier PHP versions > there already was an (unset) cast to unconditionally turn an > expression into null. We opted for > (void) instead of bringing back > (unset) for the following reasons: (1) Possible confusion about a > deprecated + removed feature coming back (e.g. avoiding old blog articles). (2) More cleanly > enforcing that (void) is a statement, rather than an expression. (3) > The similarity with the void return type to indicate that > “nothing” is returned. A possible alternative is: ! func();, that already “works” as of today, modulo possible optimisation. In any case, I think that (void) func(); is not self-explanatory, and in the event I want to ignore a result I am not supposed to ignore, I will probably write something more explicit like, $unused = func();(possibly decorated with an annotation telling static analysers not to complain that $unused is unused), or forget(func()) BTW, the RFC says that introducing the (void) cast is a backward compatible change, which is incorrect; see: https://3v4l.org/iN7OY —Claude