[RFC] Default expression

This is a feature I've wanted for a very long time! The RFC is very
straight forward, and the appendix does a great job of enumerating the
possible expressions.

Nice work all around!

Thanks, Matt! Glad you like this one (and the last one!)

Hopefully we can land it this time 🙂

Cheers,
Bilge

as soon as two or more nullable arguments are involved

I'm not sure what you mean here. I use this method all the time :)
much to the chagrin of some of my coworkers.

function stuff($foo = 'bar', $baz = 'world');

stuff(...[ ...($foo ? ['foo' => $foo] : []), ...($baz ? ['baz' =>
$baz] : [])]);

You're right; splat with keys does work. This is something my RFC
currently glosses over and should probably be rectified!

Cheers,
Bilge

I'm not sure what you mean here. I use this method all the time :) much to the chagrin of some of my coworkers.

function stuff($foo = 'bar', $baz = 'world');

stuff(...[ ...($foo ? ['foo' => $foo] : []), ...($baz ? ['baz' => $baz] : [])]);

And you are one who complains about gotos! 😲

-Mike

Great RFC, Bilge! I was already on-board after the introduction, but if I had any doubts, the examples in the appendix sold me.

Cheers,
Ben

Thanks, Ben. That means a lot to me :)

Cheers,
Bilge

(resending as I accidentally originally send a private reply instead
of sending the below to the list)

Hi gang,

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

This one already comes complete with working implementation that I've
been cooking for a little while. Considering I don't know C or PHP
internals, one might think implementing this feature would be
prohibitively difficult, but considering the amount of help and
guidance I received from Ilija, Bob and others, it would be truer to
say it would have been more difficult to fail! Huge thanks to them.

Cheers,
Bilge

Hi Bilge,
Hi :)
I like the idea, but see some potential for issues with ambiguity,
which I don't see mentioned in the RFC as "solved".

Example 1:

function foo($paramA, $default = false) {}
foo( default: default ); // <= Will this be handled correctly ?

No, but not because of my RFC, but because $paramA is a required
parameter that was not specified. Assuming that was just a typo, the
following works as expected:

function foo($paramA = 1, $default = false) {
    var_dump($default);
}
foo(default: default); // bool(false)

Example 2:

callme(
    match($a) {
        10 => $a * 10,
        20 => $a * 20,
        default => $a * default, // <= Based on a test in the PR this 
should work. Could you confirm ?
    }
);

Yes.

Example 3:

switch($a) {
    case 'foo':
        return callMe($a, default); // I presume this shouldn't be a 
problem, but might still be good to have a test for this ?
    default:
        return callMe(10, default); // I presume this shouldn't be a 
problem, but might still be good to have a test for this ?
}

Yes.

On that note, might it be an idea to introduce a separate token for
the default keyword when used as a default expression in a function
call to reduce ambiguity ?
Considering the Bison grammar compiles, I believe there can be no
ambiguity. I specifically picked default because I think it is the
most intuitive keyword to use for this, and it's conveniently already a
reserved word.

Cheers,
Bilge

Hi gang,

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

This one already comes complete with working implementation that I've
been cooking for a little while. Considering I don't know C or PHP
internals, one might think implementing this feature would be
prohibitively difficult, but considering the amount of help and guidance
I received from Ilija, Bob and others, it would be truer to say it would
have been more difficult to fail! Huge thanks to them.

Cheers,
Bilge

I am still not fully sold on this, but I like it a lot better than the previous attempt at a default keyword. It's good that you mention named arguments, as those do replace like 95% of the use cases for "put default here" in potential function calls, and the ones it doesn't, you call out explicitly as the justification for this RFC.

The approach here seems reasonable overall. The mental model I have from the RFC is "yoink the default value out of the function, drop it into this expression embedded in the function call, and let the chips fall where they may." Is that about accurate?

My main holdup is the need. I... can't recall ever having a situation where this is something I needed. Some of the examples show valid use cases (eg, the "default plus this binary flag" example), but again, I've never actually run into that myself in practice.

Potentially the most useful place would be in attributes. Take crell\serde (:p) for instance:

#[SequenceField(implodeOn: default . ' ', joinOn: ' ' . default . ' ')]

Where you may just want it to be a little more readable, but aren't interested in the default implosion. In attributes, it has to be a static expression and I think this passes that test? At least that is one place I would find most useful.

Then there are things like the example I gave before, where you need to call some library code as library code and pass through the intentions. It also gets us one step closer to something like these shenanigans:

function configureSerializer(Serde $serializer = new SerdeCommon(formatters: default as $formatters));

Where we can call configureSerializer(formatters: new JsonStreamFormatter()).

Some pretty interesting stuff.

My other concern is the list of supported expression types. I understand how the implementation would naturally make all of those syntactically valid, but it seems many of them, if not most, are semantically nonsensical. Eg, default > 1 would take a presumably numeric default value and output a boolean, which should really never be type compatible with the function being called. (A param type of int|bool is a code smell at best, and a fatal waiting to happen at worst.) In practice, I think a majority of those expressions would be logically nonsensical, so I wonder if it would be better to only allow a few reasonable ones and block the others, to keep people from thinking nonsensical code would do something useful.

I'm reasonably certain you can write nonsensical PHP without this feature. I don't think we should be the nanny of developers.

— Rob

The approach here seems reasonable overall. The mental model I have from the RFC is "yoink the default value out of the function, drop it into this expression embedded in the function call, and let the chips fall where they may." Is that about accurate?
Yes, as it happens. That is the approach we took, because the
alternative would have been changing how values are sent to functions,
which would have required a lot more changes to the engine with no clear
benefit. Internally it literally calls the reflection API, but a
low-level call, that elides the class instantiation and unnecessary
hoops of the public interface that would just slow it down.
My main holdup is the need. I... can't recall ever having a situation where this is something I needed. Some of the examples show valid use cases (eg, the "default plus this binary flag" example), but again, I've never actually run into that myself in practice.
That's fine. Not everyone will have such a need, and of those that do,
I'm willing to bet it will be rare or uncommon at best. But for those
times it is needed, the frequency by which it is needed in no way
diminishes its usefulness.I rarely use goto but that doesn't mean we
shouldn't have the feature.
My other concern is the list of supported expression types. I understand how the implementation would naturally make all of those syntactically valid, but it seems many of them, if not most, are semantically nonsensical. Eg, default > 1 would take a presumably numeric default value and output a boolean, which should really never be type compatible with the function being called. (A param type of int|bool is a code smell at best, and a fatal waiting to happen at worst.) In practice, I think a majority of those expressions would be logically nonsensical, so I wonder if it would be better to only allow a few reasonable ones and block the others, to keep people from thinking nonsensical code would do something useful.

Since you're not the only one raising this, I will address it, but just
to say there is no good reason, in my mind, to ever prohibit the
expressiveness. To quote Rob

I'm reasonably certain you can write nonsensical PHP without this
feature. I don't think we should be the nanny of developers.

I fully agree with that sentiment. It seems to be biting me that I went
to the trouble of listing out every permutation of what /expression/
means where perhaps this criticism would not have been levied at all had
I chosen not to do so. Why does that matter? Because PHP already allows
you to do many more ridiculous things, they're just not routinely
presented to you so they're not part of your mind map. The end-user
documentation will also not mention the nonsense cases, so the average
developer will not think of them. You can write, include(1 + 1);,
because include() accepts an expression. You will get: "Failed opening
'2' for inclusion". Should we restrict that? No, because that's just how
expressions work in any context where they're allowed. 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.

Cheers,
Bilge

My other concern is the list of supported expression types. I
understand how the implementation would naturally make all of those
syntactically valid, but it seems many of them, if not most, are
semantically nonsensical.

I tend to agree with Larry and John that the list of operators should be
restricted - we can always allow more in future, but restricting later
is much harder.

A few rules that seem logical to me:

1. The expression should be reasonably guaranteed to produce the same
   type as the actual default.

• No casts
• No comparison operators, because they produce booleans from
  non-boolean input
• No "<=>". Technically, it has an integer result, but it's rare to use
  it as one, rather than a kind of three-value boolean
• No "instanceof"
• No "empty"

2. The expression should not have side effects (outside of exotic
   operator overloads).

• No "include", "require", etc
• No "throw"
• No "print"
• Borderline, but I would also say no "clone"

3. The expression should be passing additional information into the
   function, not pulling information out of it. The syntax shouldn't be a
   way to write obfuscated reflection, or invert data flow from callee to
   caller.

• No assignments.
• No ternaries with "default" on the left-hand side - "$foo ? $bar :
  default" is acting on local knowledge, but "default ? $foo : $bar" is
  acting on information the caller shouldn't know
• Same for "?:" and "??"
• No "match" with "default" as the condition or branch, for the same
  reason. "match($foo) { $bar => default }" is fine, match(default) { ...
  }" or "match($foo) { default => ... }" are not.

Note that these can be seen as aspects of the same rule: the aim of the
expression should be to transform the default value into another value
of the same type, not to pull it out and perform arbitrary operations
based on it.

I believe that leaves us with:

• Arithmetic operators: binary + - * / % **, unary + -
• Bitwise operators: & | ^ << >>  ~
• Boolean operators: && || and or xor !
• Conditions with default on the RHS: $foo ? $bar : default, $foo ?:
  default, $foo ?? default, match($foo) { $bar => default }
• Parentheses: (((default)))

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

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.

Regards,

--
Rowan Tommins
[IMSoP]

Hi gang,

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

Seems like you are missing an option for your theme example, which would
be to simply extend the Config class?

While I can see the value in the concept of default , I think it's a
mistake to allow default to be used as a generic operand as shown in the
RFC appendix. It seems to me that the whole point of something like
default is to not have to worry about what the upstream API wanted for
that value, but the second you start allowing operations where default
is an operand you've reintroduced the problem you were trying to avoid if
the upstream API were to change the type of what default ultimately
resolves to. Worse actually because now I have no idea what default is
when I read code without having to dig up the upstream API.

If the underlying API changes the argument type, consumers will have an
issue regardless. For those cases where the expression is simply default,
you'd actually be protected from the API change, which is a net benefit
already.

This also protects the user from changes in the argument names.

Other thoughts here are what happens when default resolves to an object
or enumeration or something complex? Your original example had CuteTheme ,
so can you call a method of default ?? I could entirely see someone doing
something like this for example:

enum Foo:string {
// cases

public function buildSomeValidBasedOnCase(): int { // ... }

}

F(MyClass::makeBasedOnValue(default->buildSomeValidBasedOnCase()))

IMO most operators listed in the appendix should be disallowed. I can see
the value of default | JSON_PRETTY_PRINT, but I am pretty strongly
opposed to the idea of introducing a "conditional based on the default
value of an upstream API call" concept of default >=1 .

Other thoughts here are what happens when |default| resolves to an
object or enumeration or something complex? Your original example had
|CuteTheme| , so can you call a method of |default| ?? I could
entirely see someone doing something like this for example:

enum Foo:string {
    // cases

    public function buildSomeValidBasedOnCase(): int { // ... }
}

F(MyClass::makeBasedOnValue(default->buildSomeValidBasedOnCase()))

As you have written it, no, you will get a parser error: Parse error:
syntax error, unexpected token "->", expecting ")"

However, you can wrap the default in parens as in the following example:

class C {
    function F() {
        echo 'lol';
    }
}

function G($V = new C) {}

G((default)->F()); // lol

For me there is another question. When using interfaces and classes,
default values can be introduced, like this:

interface CompressionInterface
{
    public function compress(string $data, int $level): string;
}

class GzipCompression implements CompressionInterface
{
    public function compress(string $data, int $level = 4): string
    {
        // do something
    }
}

When I have the GzipCompression class, I would know there is a default
value for $level, but when using the interface there might or might not
be a default value, depending on the implementation. As far as I read
the RFC, using "default" when there is no default would lead to a
runtime exception, but there is no way of finding out if there is a
default if you do not already know. Being able to test that could be
useful, although I am not sure about the syntax for that. In the example
when getting CompressionInterface, I might test for the existence of a
default value of $level and leave it at the default if there is a
default (maybe I know that some implementations have a default value,
others don't). One could test the specific implementation with
instanceof checks, but the advantage of "default" could be that you do
not need to know the implementation and could only adapt to possibly
defined default values.

Hi Andreas,

Thanks for this question; I find this super interesting because it's
something we haven't thought about yet. I must admit I completely
overlooked that, whilst an interface /can/ require implementers to
specify a default, in the case that they do not, it is still valid for
implementations to selectively elect to provide one. Therefore I can
append to your example the following case (I removed the string return
type for now):

class ZipCompression implements CompressionInterface
{
    public function compress(string $data, int $level)
    {
        var_dump($level);
    }
}

new GzipCompression()->compress('', default ?? 6);
new ZipCompression()->compress('', default ?? 6);

In this case, we get the following output:

int(4)
Fatal error: Uncaught ValueError: Cannot pass default to required
parameter 2 of ZipCompression::compress()

I would like to fix this if possible, because I think this should be
valid, with emphasis on /if possible/, because it may be prohibitively
complex. Will update later.

Cheers,
Bilge

interface CompressionInterface
{
    public function compress(string $data, int $level): string;
}

class GzipCompression implements CompressionInterface
{
    public function compress(string $data, int $level = 4): string
    {
        // do something
    }
}

When I have the GzipCompression class, I would know there is a default
value for $level, but when using the interface there might or might not
be a default value, depending on the implementation.

This isn't unique to defaults; GzipCompression could also widen the type to int|string, for instance, and there's no syntax for detecting that either.

If you have access to change class GzipCompression, you can resolve this by creating an additional interface:

interface SimplifiedCompressionInterface extends CompressionInterface
{
    public function compress(string $data, int $level = 4): string;
}
class GzipCompression implements SimplifiedCompressionInterface ...

Then, if we can agree an implementation, you could write:

/** @var CompressionInterface $comp */
$comp->compress($myData, $comp instanceof SimplifiedCompressionInterface ? default : MY_DEFAULT_LEVEL);

If you don't have access to change the hierarchy, then what you're probably looking for is structural typing, or implicit interfaces - i.e. a way to ask "does this object meet these criteria". For instance, some imaginary pattern matching on the signature:

/** @var CompressionInterface $comp */
$comp->compress($myData, $comp is { compress(string, optional int) } ? default : MY_DEFAULT_LEVEL);

Note how, in both cases, we're not asserting anything about the default value itself, only that the signature defines the parameter as optional. It's actually a bit of a quirk that the interface has to specify a value, rather than just stating this:

interface SimplifiedCompressionInterface extends CompressionInterface
{
    public function compress(string $data, optional int $level): string;
}

Regards,

Rowan Tommins
[IMSoP]

Hey Bilge,
Hi :)

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

Great work overall, I'm all for it and even though it's not something
I saw myself using a whole lot, the json_encode example sold me on it
being more useful than I initially thought.
Thanks! I concede, this is one of those tools for your toolbox that you
will seldom reach for, but comes in very handy whenever you do.

One question (sorry if someone already asked, I scanned the thread but
it is getting long..):
I don't blame you. I'll summarise the main takeaways in the RFC later.

Taking this example from the RFC:

    function g($p = null) {
        f($p ?? default);
    }

Could you go one step further and use default by default but still
allow null to be passed in?

    function g($p = default) {
        f($p);
    }

No. The RFC has a very specific and singular focus in this regard: to
permit default /only/ in function call contexts. That is, although
default is a valid expression, it cannot be passed around or stored in
a variable. Since this is a function definition, rather than a call,
this will result in a compiler error. The specific error we get in this
case is: "Fatal error: Constant expression contains invalid operations".

Cheers,
Bilge

Hey Jordi,

One question (sorry if someone already asked, I scanned the thread but
it is getting long..):

Taking this example from the RFC:

    function g($p = null) {
        f($p ?? default);
    }

Could you go one step further and use default by default but still
allow null to be passed in?

    function g($p = default) {
        f($p);
    }

I suppose this would mean $p has to hold this "default" value until a
function call is reached, at which point it would resolve to whatever
the default is. This probably complicates things for very little gain
but I had to ask.

First, it would be some sort of spooky action at a distance, likely add
a new zval type etc.; lots of special handling for a likely minor benefit.

Second, I'd expect that bit of syntax do be useful in inheritance - like
you implement or override a parent class/interface method specifying a
default; then you can just use the default of the parent method.

Bob

Hi,
Hi :)

I haven't followed the entire thread in depth so I apologise if this
was already answered, but I haven't noticed it being
mentioned/clarified yet.
Don't worry, you're right, this is an important topic that I was still
finalising in the past 48 hours and is still an omission from the RFC,
and as such we haven't discussed it on the list yet.
Can you clarify in the following, is the arm comparing against match's
default or the parameter's default? Or to put it another way, in the
second call, If $arg is 2, will the match error out due to an
unmatched subject, or will it pass 1 to F?

function F(int $foo =1) {}

F(match(default) {default =>default });
F(match($arg) {'a' =>0,default =>default });

Thank you for your (excellent) question. The answer is it will pass 1,
and the reason is as follows.

F(match(default) { default => default }); is interpreted as match (default expression) { default arm => default expression }, therefore
the first and last defaults will be substituted with the argument's
default, but not the middle one. However, that is only the case when the
default arm is written exactly as default.

You can turn the condition into an expression, in which case all three
will act as expressions and be substituted accordingly, e.g.
F(match(default) { (int) default => default });.

Since the default condition is now an expression, you can still have a
default arm in addition to this, e.g. the following would be valid:

F(match(default) {
    (int) default => default,
    default => default,
});

Whilst this is a curiosity, consider that passing match expressions
directly to arguments is something I personally have never witnessed and
that goes doubly for combining it with default. So, whilst it is
interesting to know, and important for the RFC to state the specific
semantics of this scenario, the practical applications are presumed slim
to none.

Cheers,
Bilge

Using 'default' as a place holder for (not) passing an argument seems
useful. I am however much uncertain about using composition with the
keyword in expressions.
Presumably you mean ternary and null coalesce would still be acceptable?
Otherwise, it is little more than an alternative to named parameters,
which is seldom useful. Ternary and null coalesce are, themselves,
expressions so I expect that is why I was guided towards treating
default the same way. Whilst the applications beyond use in
conditionals still strikes me as limited, it also appears equally
harmless.  Though the number of people whom feel its use in expression
should be limited is steadily growing, I'm still waiting on someone to
publish an exclusion list with justification for each exclusion, because
again, I think a plurality of possibilities are harmless. Nevertheless,
an inclusion list was produced by IMSoP, based on what he felt would be
useful, but I think arbitrary exclusions are unintuitive for developers
and likely to limit someone from doing something justifiably useful that
we didn't conceive at the time.
I also think that implementation would probably be significantly less
complex as it was only used for placeholders.
Would it? I was told that the alternative was to modify all the SEND
opcodes, which is anything but less complex. The current implementation
seems necessarily simple to me since it just adds a single new opcode
that doesn't interfere with anything else. I say necessarily, because if
it was actually complex, I probably couldn't have written the solution
given my limited ability.
It's likely something that can be handled in the parser.

Clearly this problem cannot be solved solely in the parser. If I assume
you're proposing to just allow default in conditionals, what is
responsible for compiling that and how will the called function know
what to do with it?

Cheers,
Bilge

One thought re-reading the RFC.

abstract class Theme {
public function bar();
}

class CuteTheme extends Theme {
public function foo();
}

class Config {
public function __construct(Theme $theme = new CuteTheme()) {}
}

$a = new Config(default->foo());
In the proposed (updated) RFC would this be proposed to work? If so this should be added to the discussion section as something I think is equally as problematic as union types. I don't think saying "Union and Mixed" is broad enough. In this case it would actually have to only allow Theme (whatever that was) and prevent you from calling foo() because that isn't a member of Theme . Otherwise it's the same problem as union types in a different color.
Coogle

Hi gang,

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

Now the dust has settled, I've updated the RFC to version 1.1. The
premise of the RFC is unchanged, but the proposal has been expanded and
a discussion section added to summarise the ~100 message thread to
capture the major concerns raised in a condensed format. I hope I've
done a good job of fairly and accurately representing your concerns, but
if not please correct me.

Furthermore, a secondary vote has been added. The secondary vote will be
open to all (whether in favour or against the proposal) to capture
alternative implementations you might also be in favour of. If the
primary vote passes, the secondary vote won't matter, but otherwise it
may help guide our sails in future.

Kind regards,
Bilge

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

Now the dust has settled, I've updated the RFC to version 1.1. The
premise of the RFC is unchanged, but the proposal has been expanded and
a discussion section added to summarise the ~100 message thread to
capture the major concerns raised in a condensed format. I hope I've
done a good job of fairly and accurately representing your concerns, but
if not please correct me.

Hi,

I will try to find some time over the next few days to write something up, because there are some clear misunderstandings in that current text.

• It's not about union types. There are lots of examples using union types, because they're easier to illustrate than class/interface hierarchies, but "disallowing default to be passed to union types" wouldn't even help with the example directly below that sentence.
• The paragraph about "Default as a contract" misses the point by a mile. There's a world of difference between "the new version of this library has different behaviour" and "the new version of this library gives a TypeError in my code which used to work".
• It's not about "critics" and "preferred versions", or it doesn't need to be. We can say "here are some situations where it might be useful; and here are some situations where it would cause unexpected errors; do we think the benefits of one outweigh the cost/risk of the other?"

I already shared this with you, but for the benefit of the wider audience, here are some examples I've put together of when users might vary the types of defaults, and how that would cause errors with the proposed feature: https://gist.github.com/IMSoP/16e2422d86e3ab513d6b0658009d0c06 I stress again, I'm not trying to win points in a popularity contest here, I'm trying to make sure we properly lay out the pros and cons of the proposal.

It's worth noting that the drawback being pointed out is similar to one encountered with named arguments. Nikita dedicated a substantial part of that RFC to discussing the problem, its possible solutions, and the impact of the proposed direction: this section https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance and this one https://wiki.php.net/rfc/named_params#to_parameter_name_changes_during_inheritance and most of this one https://wiki.php.net/rfc/named_params#backwards_incompatible_changes

Regards,

Rowan Tommins
[IMSoP]

New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might enjoy this one. Hit me with any feedback.

Now the dust has settled, I've updated the RFC to version 1.1. The
premise of the RFC is unchanged, but the proposal has been expanded
and a discussion section added to summarise the ~100 message thread to
capture the major concerns raised in a condensed format. I hope I've
done a good job of fairly and accurately representing your concerns,
but if not please correct me.

As promised, I have written up a full explanation of the type safety
issues here: https://wiki.php.net/rfc/default_expression/type_safety

I have tried to write this as a neutral description of the problem and
the possible approaches we could take, to be inserted directly into the
current RFC, rather than as a counter-opinion or a narrative of who said
what.

I have included the 4 options which I believe are the only ones we have;
it is then a matter of opinion which we think is best. For the record,
my opinion remains that option 3 (limit to conditional expressions) is
preferable, but I have assumed the RFC will continue to advocate for
option 1 (allow any expression and assume problems will be rare).

I hope I have explained it clearly enough this time to overcome the
previous misunderstandings of where the issue lies.

Regards,

--
Rowan Tommins
[IMSoP]