> Le 30 janv. 2025 à 16:51, Tim Düsterhus <t...@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
