On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
>
>
> Even then, I look at that list and see more problems than use cases. As the
> RFC points out, library authors already worry about the maintenance burden of
> named argument support, will they now also need to question whether someone
> is relying on "default + 1" having some specific effect?
> Maybe we should instead require justification for each addition:
> - Bitwise | is nicely demonstrated in the RFC
> - Bitwise & could probably be justified on similar grounds
> - "$foo ? $bar : default" is discussed in the RFC
> - The other "conditions with default on the RHS" in my shortlist above fit
> the same basic use case
>
>
IMO the operations that make sense in this context are:
- Some Bitwise operators: & | ^
- Conditions with default on the RHS: $foo ? $bar : default, $foo ?: default,
$foo ?? default, match($foo) { $bar => default }
- Parentheses: (((default)))
> Beyond that, I'm struggling to think of meaningful uses: "whatever the
> function sets as its default, do the opposite"; "whatever number the function
> sets as default, raise it to the power of 3"; etc. Again, they can easily be
> added in later versions, if a use case is pointed out.
I 100% agree.
> G((default)->F()); // lol
> Special-casing the T_DEFAULT grammar would not only bloat the grammar rules
> but also increase the chance that new expression grammars introduced in
> future, which could conveniently interoperate with `default`, would be
> unintentionally excluded by omission.
I won't vote for this RFC if the above code is valid, FWIW. Unlike include ,
default is a special-case with a very specific purpose -- one that is reaching
into someone else's API in a way the developer of that library doesn't
explicitly permit. It should not become a fast easy way to inject a new
potentially complex dependency which is what allowing a full expression support
would allow.
The fact that Reflection allows me to pull out a private member doesn't mean
accessing private members of objects should be given its own language syntax.
Frankly, not only should the op list be limited but ideally it should also only
be valid based on the type of the upstream API call (e.g. bitwise operators
should only be valid if the upstream API call has a type int ).
