Hi all,
I've been following the discussion on the Default Expression RFC, and while
I appreciate the effort to introduce more flexibility in handling default
values, I have some significant concerns about this proposal. I'd like to
share my thoughts and invite further discussion.
1. Complexity vs
On 27/08/2024 16:03, John Bafford wrote:
I'm not sure this could even work at all. The "default" parameter to
gettype() isn't the default value of the third parameter to
json_encode(). It's the default value of the first parameter to
gettype(). Which would probably fail, since gettype()'s first p
> On Aug 27, 2024, at 10:14, Rowan Tommins [IMSoP] wrote:
>
> The only expressions that are in some sense "safe" are those that can apply
> equally to any possible type that the function could in future set as the
> default. In theory, that includes a match statement with an arm of "default
On 27 August 2024 14:14:03 BST, Bilge wrote:
> 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 some
On 27/08/2024 12:56, Derick Rethans wrote:
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
On Sat, 24 Aug 2024, Bilge wrote:
> 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.
I liked this up to the point where I saw:
$f = fn ($v = 1, $default = 2) => $v + $default;
var_dump($f(defaul
On Mon, Aug 26, 2024 at 11:58 PM Bilge wrote:
> In case it matters, my initial inclination was also to do what some others
> have suggested, and modify the SEND opcodes so that the default is not
> actually looked up using reflection at all, but rather we just send nothing
> to the function and i
On Tue, Aug 27, 2024 at 6:23 AM John Coggeshall wrote:
>
> But let's not just say "no expressions" - I think there's been some
> demonstrated value from a lot of these.
>
>
> Honest to god I don't think I've read from one person to come out and say
> "no expressions".
>
Well...
I think it's caus
On 27 August 2024 05:20:32 BST, John Coggeshall wrote:
>> I DO think there are likely whole categories of expressions we can likely
>> say "no" to - anything where the default represents a union type (and
>> _mixed_ is a union type) should likely only allow default by itself or as a
>> bare
On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney
wrote:
> You'll likely identify the increased delay in such cases. Generally speaking
> these sorts of default values don't change a ton, but it's not unlikely that
> you may say "I'd like half that delay" or "twice that delay". But a better
On Aug 26 2024, at 5:57 pm, Bilge wrote:
> In case it matters, my initial inclination was also to do what some others
> have suggested, and modify the SEND opcodes so that the default is not
> actually looked up using reflection at all, but rather we just send nothing
> to the function and it
On 26/08/2024 11:32, Andreas Heigl wrote:
Hey folks.
Am 26.08.24 um 11:26 schrieb Bilge:
On 26/08/2024 10:03, Andreas Leathley wrote:
On 24.08.24 18:49, Bilge wrote:
For me there is another question. When using interfaces and classes,
default values can be introduced, like this:
interface Co
On 26 August 2024 22:27:55 BST, Matthew Weier O'Phinney
wrote:
>How exactly is this worrisome? Consider this:
>
>class A {
>public function __construct(private LogInterface $logger = new
>DefaultLogger()) { }
>}
>
>class ProxiedLogger implements LogInterface { ... }
>
>
On 26/08/2024 22:27, Matthew Weier O'Phinney wrote:
Again, there are a few lists going around on this thread, and I hope
that Bilge is taking notes to add to the RFC, and working with the
folks who helped him with implementation to determine what is and is
not possible in terms of the grammar s
On Mon, Aug 26, 2024 at 3:45 PM John Coggeshall wrote:
>
>
> On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplica
On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney
wrote:
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts.
> These might require testing for non-zero
On 26 August 2024 20:27:59 BST, Mike Schinkel wrote:
>So, nullable is an equivalent to the union-type concern my discussion with
>John Coggeshall uncovered, correct?
It's not really anything to do with nulls, or unions. It's somewhat related to
"contravariance of input": that it should alwa
> On Aug 26, 2024, at 8:28 AM, Rowan Tommins [IMSoP]
> wrote:
>
> On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>>> You ask how a library can provide access to that default, and the answer is
>>> generally pretty trivial: define a public constant, and refer to it in the
>>> parameter def
On 26/08/2024 15:20, Stephen Reay wrote:
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
On Aug 26 2024, at 2:39 pm, Bilge wrote:
>
> I like this approach. I'm still not sure I'd want to pursue adding
> exclusions, but if we can identify something that's obviously bad and/or
> dangerous then we can consider that short list for exclusion. That is much
> more compelling than starti
On 26/08/2024 19:11, Matthew Weier O'Phinney wrote:
On Mon, Aug 26, 2024, 12:02 PM Larry Garfield
wrote:
I recognize that "limiting the allowed expression structures
arbitrarily is way harder than it sounds" is a valid argument as
well. At the same time, John C has offered some
On Mon, Aug 26, 2024, 12:02 PM Larry Garfield
wrote:
> On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> > On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> > wrote:
> >> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> >> > You're absolutely right, I would be interested to see any via
> From the example you gave it appears that we can have a concrete problem when:
> 1. There is a parameter with a default value,
> 2. That parameter is type-hinted,
> 3. The hinted type is declared as a union type,
> 4. An earlier version of the library initialized the default with a value
> havi
Hey Jordi,
On 26.8.2024 13:55:52, Jordi Boggiano wrote:
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
On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
> wrote:
>> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
>> > You're absolutely right, I would be interested to see any viable patch
>> > that effectively implements a set of restriction
On Mon, Aug 26, 2024 at 12:47 PM Rowan Tommins [IMSoP]
wrote:
> Another approach that occurred to me was in the executor: rather than
> evaluating to the default value immediately, "default" could resolve to a
> special value, essentially wrapping the reflection parameter info. Then
> when the fu
On Mon, Aug 26, 2024 at 5:36 AM, Jakob Givoni <[ja...@givoni.dk](mailto:On Mon,
Aug 26, 2024 at 5:36 AM, Jakob Givoni < wrote
> "default" should not evaluate to a value before sending it as an argument to
> the function or method.
I have no dog in this fight, but I agree with the above. Plus, h
> On 24 Aug 2024, at 23:49, Bilge wrote:
>
> 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 l
On 26/08/2024 12:55, Jordi Boggiano wrote:
Hey Bilge,
Hi :)
On 24.08.2024 18:49, Bilge wrote:
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 s
On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>> On Aug 26, 2024, at 3:28 AM, Rowan Tommins [IMSoP]
>> wrote:
>> I was responding to someone justifying anything and everything the proposal
>> allows, because Reflection already allows it. If the feature was "first
>> class syntax to access
On Mon, 26 Aug 2024, at 11:43, Mike Schinkel wrote:
>> You ask how a library can provide access to that default, and the answer is
>> generally pretty trivial: define a public constant, and refer to it in the
>> parameter definition.
>
> A global? Really?
I didn't say "global", I said "public".
Hey Bilge,
On 24.08.2024 18:49, Bilge wrote:
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_e
On Mon, Aug 26, 2024 at 12:49 PM Rowan Tommins [IMSoP]
wrote:
> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> > You're absolutely right, I would be interested to see any viable patch
> > that effectively implements a set of restrictions on how `default` may
> > be used. Requesting it be done at t
On Mon, 26 Aug 2024, at 10:03, Andreas Leathley wrote:
> interface CompressionInterface
> {
> public function compress(string $data, int $level): string;
> }
>
> class GzipCompression implements CompressionInterface
> {
> public function compress(string $data, int $level = 4): string
>
On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
> You're absolutely right, I would be interested to see any viable patch
> that effectively implements a set of restrictions on how `default` may
> be used. Requesting it be done at the parser level was not meant as a
> gotcha, that's just how I (with
> On Aug 26, 2024, at 2:26 AM, John Coggeshall wrote:
> The proposal in the RFC creates a new dependency and backward compatibility
> issue for API developers that currently does not exist. It is not just
> because it allows for non-sensical expressions, but that it allows perfectly
> sensical
On 26/08/2024 08:28, Rowan Tommins [IMSoP] wrote:
As far as I can see, nobody has actually justified reading values out in this
way, only said it's a side-effect of the current implementation.
It's pretty useful for testing.
Aside: one of those examples brings up an interesting question: is th
Hey folks.
Am 26.08.24 um 11:26 schrieb Bilge:
On 26/08/2024 10:03, Andreas Leathley wrote:
On 24.08.24 18:49, Bilge wrote:
For me there is another question. When using interfaces and classes,
default values can be introduced, like this:
interface CompressionInterface
{
public function co
On 26/08/2024 11:11, Andreas Leathley wrote:
On 26.08.24 11:26, Bilge wrote:
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.
That would be a way to fix it, to basically ma
On 26.08.24 11:26, Bilge wrote:
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 v
On 26/08/2024 10:03, Andreas Leathley wrote:
On 24.08.24 18:49, Bilge wrote:
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;
}
clas
On 26/08/2024 09:58, Christoph M. Becker wrote:
On 25.08.2024 at 23:51, Bilge wrote:
If you believe I am incorrect about this, I encourage you to submit a
(working) Bison patch to demonstrate how a restricted expression grammar
subset can still recurse with the unrestricted superset, then we ca
On 24.08.24 18:49, Bilge wrote:
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 do
On 25.08.2024 at 23:51, Bilge wrote:
> If you believe I am incorrect about this, I encourage you to submit a
> (working) Bison patch to demonstrate how a restricted expression grammar
> subset can still recurse with the unrestricted superset, then we can
> start having this discussion more serious
On 26 August 2024 05:44:44 BST, Mike Schinkel wrote:
>> On Aug 25, 2024, at 12:21 PM, Rowan Tommins [IMSoP]
>> wrote:
>> The Reflection API is a bit like the Advanced Settings panel in a piece of
>> software, it comes with a big "Proceed with Caution" warning. You only move
>> something fr
(TL;DR; Down the thread a bit I put together a concrete example of why I'm
opposed to this RFC)
On Aug 26 2024, at 12:44 am, Mike Schinkel wrote:
> Speaking only to #1 for the moment, there are many different places in PHP
> where certain expressions make no sense either, yet I do not see those
This is a general comment so not replying to anyone in particular hence the
top-posting (but with some bottom-posts in particular reply below.)
The RFC — which I am neither pro nor con for — proposes allowing default to be
an expression, and while many like and support the RFC others are (not qu
On Aug 25 2024, at 6:42 pm, Bilge wrote:
> On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
> > It doesn't, unfortunately, persuade me that the behaviour proposed is
> > sensible.
>
> It should. But since it has apparently failed in that regard, I suggest you
> take me up on my challenge to i
On Aug 25 2024, at 5:51 pm, Bilge wrote:
> If you believe I am incorrect about this, I encourage you to submit a
> (working) Bison patch to demonstrate how a restricted expression grammar
> subset can still recurse with the unrestricted superset, then we can start
> having this discussion mor
On 25 August 2024 23:42:20 BST, Bilge wrote:
>On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
>> It doesn't, unfortunately, persuade me that the behaviour proposed is
>> sensible.
>
>It should. But since it has apparently failed in that regard, I suggest you
>take me up on my challenge to i
On 26.8.2024 00:31:57, Rowan Tommins [IMSoP] wrote:
I'm not an expert on parsers, and never claimed to be, so it's not particularly surprising to me
that I've overlooked a reason why "expr ?: default" can't be included without also
including "default ?: expr", and will just have to take your wo
On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
It doesn't, unfortunately, persuade me that the behaviour proposed is sensible.
It should. But since it has apparently failed in that regard, I suggest
you take me up on my challenge to implement the grammar you want with a
patch and you will
On 25 August 2024 22:51:45 BST, Bilge wrote:
>Great! I'm glad we're finally getting to this, because I think this is what
>you, and everyone advocating for a restricted grammar, is actually missing.
>You think you've caught me in some kind of "gotcha" moment, but fair warning,
>I'm about to
On 25/08/2024 22:09, Rowan Tommins [IMSoP] wrote:
On 25 August 2024 21:00:03 BST, Bilge wrote:
class Suspension {
/**
* @param int $delay Specifies the delay in milliseconds.
*/
public function suspend(int $delay = 1_000) {
var_dump($delay);
}
}
class MySus
On 25 August 2024 21:29:45 BST, John Bafford wrote:
>This is only by current convention. It used to be that parameter names were
>not part of the API contract, but now with named parameters, they are.
Indeed, and it remains highly controversial among library authors, and is even
used as a j
On 25 August 2024 21:00:03 BST, Bilge wrote:
>class Suspension {
> /**
> * @param int $delay Specifies the delay in milliseconds.
> */
> public function suspend(int $delay = 1_000) {
> var_dump($delay);
> }
>}
>
>class MySuspension extends Suspension {
> /**
> * @
On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote:
> On 25/08/2024 14:35, Larry Garfield wrote:
>> 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
> public function suspend(float|int|null $delay = null) {
> parent::suspend((int)(($delay ?? 0) * 1000) ?: default);
> }
> }
>
> new MySuspension()->suspend(2.2345); // int(2234)
> Not only have I demonstrated the need to use multiplication or division
> to change the scale, but also the need to
On Aug 25, 2024, at 14:46, Rowan Tommins [IMSoP] wrote:
>
> On 25/08/2024 18:44, John Bafford wrote:
>
>> Although I'm not sold on the idea of using default as part of an
>> expression, I would argue that a default function parameter value is
>> fair game to be read and manipulated by callers.
On 25/08/2024 18:46, Rowan Tommins [IMSoP] wrote:
On 25/08/2024 18:30, Bilge wrote:
I apologise for coming on strong, but I put a lot of effort into
this, so I take exception to the implication that anyone involved
took the easy way out to arrive at this (our best) solution.
I apologise for
On 25/08/2024 17:05, Rowan Tommins [IMSoP] wrote:
On 25/08/2024 16:29, Bilge wrote:
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
contex
On Sun, Aug 25, 2024, at 20:46, Rowan Tommins [IMSoP] wrote:
> On 25/08/2024 18:44, John Bafford wrote:
>
>> Although I'm not sold on the idea of using default as part of an
>> expression, I would argue that a default function parameter value is
>> fair game to be read and manipulated by callers
On 25/08/2024 18:44, John Bafford wrote:
Although I'm not sold on the idea of using default as part of an
expression, I would argue that a default function parameter value is
fair game to be read and manipulated by callers. If the default value
was intended to be private, it shouldn't be in the
On Sun, Aug 25, 2024, at 18:21, Rowan Tommins [IMSoP] wrote:
> On 25/08/2024 16:54, Rob Landers wrote:
> > Hi Rowan, you went through a lot of trouble to write this out, and the
> > reasoning makes sense to me. However, all the nonsensical things you
> > say shouldn’t be allowed are already per
On 25/08/2024 18:30, Bilge wrote:
I apologise for coming on strong, but I put a lot of effort into this,
so I take exception to the implication that anyone involved took the
easy way out to arrive at this (our best) solution.
I apologise for the inadvertent offence.
It was based solely on th
Hi Rowan,
> On Aug 25, 2024, at 11:31, Rowan Tommins [IMSoP] wrote:
>
> 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.
On 25/08/2024 18:12, Rowan Tommins [IMSoP] wrote:
For instance, rather than adding "default" to the "expr" rule in the
grammar, and then restricting it at compile-time, maybe we add a new
grammar rule "expr_with_default", usable only in expressions and with
a very limited set of productions.
On 25/08/2024 17:36, Ilija Tovilo wrote:
I don't agree with that. Constant expressions in PHP already only
support a subset of operations that expressions do. However, default
is proposed to be a true expression, i.e. one that compiles to
opcodes.
This is circular: obviously, changing the prop
Hi Rowan
On Sun, Aug 25, 2024 at 6:06 PM Rowan Tommins [IMSoP]
wrote:
>
> On 25/08/2024 16:29, Bilge wrote:
> > 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 h
> 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.
Forgot to add that I don't thi
On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] 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 some
On 25/08/2024 16:54, Rob Landers wrote:
Hi Rowan, you went through a lot of trouble to write this out, and the
reasoning makes sense to me. However, all the nonsensical things you
say shouldn’t be allowed are already perfectly allowed today, you just
have to type a bunch of boilerplate reflecti
On 25/08/2024 16:29, Bilge wrote:
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.
I think a better compar
On Sun, Aug 25, 2024, at 17:31, Rowan Tommins [IMSoP] wrote:
> On 25/08/2024 14:35, Larry Garfield wrote:
>> 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, i
On 25/08/2024 15:04, John Coggeshall wrote:
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
On 25/08/2024 14:35, Larry Garfield wrote:
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 an
On 25/08/2024 14:35, Larry Garfield wrote:
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
accur
On Aug 25 2024, at 11:11 am, Rob Landers wrote:
>
> Which operants don’t make sense?
Well certainly all of the ones toward the end of the appendix in the RFC the
RFC itself notes are non-sensical. Personally, I'm not sold on the idea default
should be an operand in an expression at all though.
On Sun, Aug 25, 2024, at 16:58, John Coggeshall wrote:
>
>
>> 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
>> a
> 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
On Sun, Aug 25, 2024, 9:06 AM John Coggeshall wrote:
>
>
> On Aug 24 2024, at 12:49 pm, Bilge wrote:
>
> 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 optio
On Sun, Aug 25, 2024, at 15:35, Larry Garfield wrote:
> On Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote:
> > 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 c
On Aug 24 2024, at 12:49 pm, Bilge wrote:
> 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 C
On Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote:
> 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 li
On Sun, Aug 25, 2024, at 12:01, Bilge wrote:
> On 25/08/2024 10:49, Juliette Reinders Folmer wrote:
> > (resending as I accidentally originally send a private reply instead
> > of sending the below to the list)
> >
> > On 24-8-2024 18:49, Bilge wrote:
> >> Hi gang,
> >>
> >> New RFC just dropped
On 25/08/2024 10:49, Juliette Reinders Folmer wrote:
(resending as I accidentally originally send a private reply instead
of sending the below to the list)
On 24-8-2024 18:49, Bilge wrote:
Hi gang,
New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
think some of you might e
(resending as I accidentally originally send a private reply instead of
sending the below to the list)
On 24-8-2024 18:49, Bilge wrote:
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 al
On 25/08/2024 04:06, Ben Ramsey wrote:
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
On Sun, Aug 25, 2024, at 04:41, Mike Schinkel wrote:
>
>
>> On Aug 24, 2024 at 5:16 PM, mailto:rob@bottled.codes>> wrote:
>> 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');
>
> On Aug 24, 2024, at 11:49, Bilge wrote:
>
> 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 li
>
> On Aug 24, 2024 at 5:16 PM, mailto:rob@bottled.codes)> wrote:
>
>
>
> 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');
>
>
>
> s
On 24/08/2024 22:14, Rob Landers wrote:
On Sat, Aug 24, 2024, at 18:49, Bilge wrote:
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 = 'w
On Sat, Aug 24, 2024, at 18:49, Bilge wrote:
> 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 lit
On 24/08/2024 18:01, Matthew Weier O'Phinney wrote:
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!
On Sat, Aug 24, 2024, 11:50 AM Bilge wrote:
> 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 is a feature I've wanted for a very long time! The RFC is very
straight forward, and the appe
95 matches
Mail list logo
