> Le 30 janv. 2025 à 16:51, Tim Düsterhus <[email protected]> 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