Hi
Am 2024-10-29 16:11, schrieb Tim Düsterhus:
Volker and I would like to start discussion on our RFC to "Support
Closures in constant expressions".
Please find the following resources for your reference:
- RFC: https://wiki.php.net/rfc/closures_in_const_expr
- Implementation: https://github.
Hi
Am 2024-11-05 18:49, schrieb Larry Garfield:
My expectation is that it's confusing, and therefore we should simply
disallow it. Which roughly translates to detecting if a closure tries
to use an unbound variable statically. Which is probably more
difficult than I make it sound. :-)
Which
On Mon, Nov 4, 2024, at 6:57 PM, Gina P. Banyard wrote:
> On Monday, 4 November 2024 at 20:32, Larry Garfield
> wrote:
>
>> On Mon, Nov 4, 2024, at 6:06 AM, Tim Düsterhus wrote:
>> >
>> > Here's another brainteaser:
>> >
>> > function foo(
>> > string $bar,
>> > Closure $baz = static fn () => $
On Monday, 4 November 2024 at 20:32, Larry Garfield
wrote:
> On Mon, Nov 4, 2024, at 6:06 AM, Tim Düsterhus wrote:
> >
> > Here's another brainteaser:
> >
> > function foo(
> > string $bar,
> > Closure $baz = static fn () => $bar,
> > ) {
> > var_dump($baz());
> > }
> >
> > foo('captured');
>
On Mon, Nov 4, 2024, at 6:06 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2024-10-31 07:16, schrieb Larry Garfield:
>> Hm. It would never occur to me to use a function for a non-class
>> constant in the first place, so I don't know. :-) Frankly I can't
>> recall the last time I used a non-class constan
Hi
Am 2024-10-30 09:31, schrieb Alexandru Pătrănescu:
So, why not allow capturing, since anyway the only place to capture are
constants and static variables?
Static variables already support arbitrary expressions since
https://wiki.php.net/rfc/arbitrary_static_variable_initializers. The RFC
Hi
Am 2024-11-04 13:33, schrieb Rob Landers:
What would you expect the semantics of that script to be?
Isn't this semantically equivalent to:
Perhaps? That's the question I am asking. Given that this is not a valid
PHP program as of now, it would as least be debatable how this is
supposed
Hi
Am 2024-10-31 15:16, schrieb Gina P. Banyard:
I very much like this feature, a bit sad that it doesn't support First
Class Callable syntax, but I understand the increased complexity this
would add.
We hope to follow-up with a separate RFC for that, once we figured out
the technical implem
On Mon, Nov 4, 2024, at 13:06, Tim Düsterhus wrote:
> Hi
>
> Am 2024-10-31 07:16, schrieb Larry Garfield:
> > Hm. It would never occur to me to use a function for a non-class
> > constant in the first place, so I don't know. :-) Frankly I can't
> > recall the last time I used a non-class con
Hi
Am 2024-10-31 08:22, schrieb Rob Landers:
To be honest, I thought it was a rhetorical question since the example
is a runtime error (passing string to a function that takes an array),
That clearly was a typo / copy-paste mistake / whatever you would like
to call it.
but on this note, we
Hi
Am 2024-10-31 07:16, schrieb Larry Garfield:
Hm. It would never occur to me to use a function for a non-class
constant in the first place, so I don't know. :-) Frankly I can't
recall the last time I used a non-class constant period. :-)
That said, PHP consts are already a bit squishy, an
Hi
Am 2024-10-30 13:06, schrieb Rob Landers:
This looks interesting, but I notice it says that the closure can
access “private properties”:
This means that Closures in property default values may access private
properties, methods, and class constants of the class where they are
defined
I
Hi
Am 2024-10-30 10:58, schrieb Michał Marcin Brzuchalski:
Personally, I'd expect short-closures be available as well, did you
though
about maybe reusing `const` token instead of `static` to make the
information visually available for users?
We do not believe the cost-benefit ratio is worth
On Thu, Oct 31, 2024, at 15:12, Gina P. Banyard wrote:
> On Thursday, 31 October 2024 at 07:22, Rob Landers wrote:
>
>> To be honest, I thought it was a rhetorical question since the example is a
>> runtime error (passing string to a function that takes an array), but on
>> this note, we alread
On Tuesday, 29 October 2024 at 15:11, Tim Düsterhus wrote:
> Hi
>
> Volker and I would like to start discussion on our RFC to "Support
> Closures in constant expressions".
>
> Please find the following resources for your reference:
>
> - RFC: https://wiki.php.net/rfc/closures_in_const_expr
> -
On Thursday, 31 October 2024 at 07:22, Rob Landers wrote:
> To be honest, I thought it was a rhetorical question since the example is a
> runtime error (passing string to a function that takes an array), but on this
> note, we already know how it should behave: https://3v4l.org/RC6b3 because,
On Thu, Oct 31, 2024, at 07:16, Larry Garfield wrote:
> On Wed, Oct 30, 2024, at 3:01 AM, Tim Düsterhus wrote:
> > Hi
> >
> > Am 2024-10-30 05:25, schrieb Larry Garfield:
> >> This seems like a good idea to me. My only real question is why we
> >> need to forbid short-closures. I fully agree t
On Wed, Oct 30, 2024, at 3:01 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2024-10-30 05:25, schrieb Larry Garfield:
>> This seems like a good idea to me. My only real question is why we
>> need to forbid short-closures. I fully agree that capturing variables
>> for such functions doesn't work. What I
Hi Tim
śr., 30 paź 2024 o 09:02 Tim Düsterhus napisał(a):
> Hi
>
> Am 2024-10-30 05:25, schrieb Larry Garfield:
> > This seems like a good idea to me. My only real question is why we
> > need to forbid short-closures. I fully agree that capturing variables
> > for such functions doesn't work.
On Tue, Oct 29, 2024, at 16:11, Tim Düsterhus wrote:
> Hi
>
> Volker and I would like to start discussion on our RFC to "Support
> Closures in constant expressions".
>
> Please find the following resources for your reference:
>
> - RFC: https://wiki.php.net/rfc/closures_in_const_expr
> - Impl
On 10/30/24 9:31 AM, Alexandru Pătrănescu wrote:
Hi Tim,
So, why not allow capturing, since anyway the only place to capture are
constants and static variables?
And this way we could have short closures with auto-capture.
If there are some technical reasons for not doing that, can we
have wri
On Wed, Oct 30, 2024 at 10:03 AM Tim Düsterhus wrote:
> Hi
>
> Am 2024-10-30 05:25, schrieb Larry Garfield:
> > This seems like a good idea to me. My only real question is why we
> > need to forbid short-closures. I fully agree that capturing variables
> > for such functions doesn't work. What
Hi
Am 2024-10-29 21:12, schrieb Valentin Udaltsov:
Will the first class callable syntax be supported?
```
#[Serialize\Custom(strtoupper(...))]
```
It is currently listed in the “Future Scope” section. Mainly, because
the implementation does not *trivially* extend to first-class callables.
W
Hi
Am 2024-10-30 05:25, schrieb Larry Garfield:
This seems like a good idea to me. My only real question is why we
need to forbid short-closures. I fully agree that capturing variables
for such functions doesn't work. What I don't understand is why that
precludes short-closures. Is it not
On Tue, Oct 29, 2024, at 10:11 AM, Tim Düsterhus wrote:
> Hi
>
> Volker and I would like to start discussion on our RFC to "Support
> Closures in constant expressions".
>
> Please find the following resources for your reference:
>
> - RFC: https://wiki.php.net/rfc/closures_in_const_expr
> - Implem
On Tuesday, 29 October 2024 at 18:14, Tim Düsterhus
wrote:
> Hi
>
> Volker and I would like to start discussion on our RFC to "Support
> Closures in constant expressions".
>
> Please find the following resources for your reference:
>
> - RFC: https://wiki.php.net/rfc/closures_in_const_expr
> - Im
26 matches
Mail list logo
