[PHP-DEV] [RFC] [VOTE] Random Extension 5.x
Hello internals. Voting began on 2022-06-14 00:00:00 (UTC) and will end on 2022-06-28 00:00:00 (UTC). https://wiki.php.net/rfc/rng_extension The implementation is not yet complete and has some issues. See TODO in Pull Request for details. https://github.com/php/php-src/pull/8094 Best Regards, Go Kudo
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Larry, Arnaud,
On Mon, 13 Jun 2022 at 13:57, Arnaud Le Blanc wrote:
>
> Auto-capture in PHP is by-value. This makes this impossible. It also makes
> explicit declarations non-necessary and much less useful.
>
Separating off some pedantism from the hopefully constructive comment,
I think some of the words in the RFC are a bit inaccurate:
> A by-value capture means that it is not possible to modify any variables from
> the outer scope:
> Because variables are bound by-value, the confusing behaviors often
> associated with closures do not exist.
> Because variables are captured by-value, Short Closures can not have
> unintended side effects.
Those statements are true for scalar values. They are not true for objects:
class Foo
{
function __construct(public string $value) {}
function __toString()
{
return $this->value;
}
}
$a = new Foo('bar');
$f = fn() {
$a->value = 'explicit scope is nice';
};
print $a; // prints "bar"
$f();
print $a; // prints 'explicit scope is nice';
Yes, I know you can avoid these types of problems by avoiding
mutability, and/or avoiding capturing variables that represent
services, but sometimes those things are needed.
When you are capturing objects that can have side effects, making that
capture be explicit is quite nice (imo). I think the different
emphasis on capturing scalar values or objects might come down to a
difference in style of how different people use closures.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On 13/06/2022 14:52, Larry Garfield wrote:
That's one perspective. The other perspective is that the proposal is to
extend closure syntax to support automatic capture.
As noted before, this is a distinction without a difference.
It's a difference in focus which is very evident in some of the comments
on this thread. For instance, Arnaud assumed that adding "use(*)" would
require a change to arrow functions, whereas that never even occurred to
me, because we're looking at the feature through a different lens.
By the way, the current RFC implies you could write this:
fn() use (&$myRef, $a) { $myRef = $a * $b; }
The RFC already covers that. $b will be auto-captured by value from scope if it exists.
See the "Explicit capture" section and its example.
So it does. I find that extremely confusing; I think it would be clearer
to error for that case, changing the proposal to:
> Short Closures support explicit by-reference capture with the |use|
keyword. Combining a short closure with explicit by-value capture
produces an error.
And the example to:
$a = 1;
fn () use (&$b) {
return $a + $b; // $a is auto-captured by value
// $b is explicitly captured by reference
}
Clearer syntax for this has been cited previously as an advantage of
use(*) or use(...):
$a = 1;
function () use (&$b, ...) { // read as "use $b by reference, everything
else by value"
return $a + $b;
}
1. Auto-capture could still over-capture without people realizing it. Whether
this is actually an issue in practice (or would be) is hard to say with
certainty; I'm not sure if it's possible to make an educated guess based on a
top-1000 analysis, so we're all trying to predict the future.
I tried to make very explicit what I was and was not disputing:
> Whether the risk of these side effects is a big problem is up for
debate, but it's wrong to suggest they don't exist.
The RFC seems to be implying that the implementation removes the side
effects, but it does not, it is users paying attention to their code
which will remove the side effects.
Arguably it's less of an issue only because short-closures are, well, short, so
less likely to reuse variables unintentionally.
Our current short closures aren't just a single *statement*, they're a
single *expression*, and that's a really significant difference, because
it means to all intents and purposes *they have no local scope*. (You
can create and use a local variable within one expression, but it
requires the kind of twisted code that only happens in code golf.)
If there are no local variables, there is nothing to be accidentally
captured. That's why the current implementation doesn't bother
optimising which variables it captures - it's pretty safe to assume that
*all* variables in the expression are either parameters or captured.
2. The syntactic indicator that "auto capture will happen". The RFC says "fn". You're
recommending "use(*)". However, changing the indicator syntax would do nothing to improve point 1.
The reason I think it would be better is because it is a more
*intentional* syntax: the author of the code is more likely to think
"I'm using an auto-capture closure, rather than an explicit-capture
closure, what effect will that have?" and readers of the code are more
likely to think "hm, this is using auto-capture, I wonder which
variables are local, and which are captured?"
Of course they can still guess wrong, but I don't think "fn" vs
"function" is a strong enough clue.
(Making fn and function synonyms sounds like it would have a lot more knock-on
effects that feel very out of scope at present.)
Off the top of my head, I can't think of any, but I admit I haven't
tried hacking it into the parser to see if anything explodes.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Arnaud,
Arnaud Le Blanc wrote:
>
> Following your comment, I have clarified a few things in the "Auto-capture
> semantics" section. This includes a list of way in which these effects can be
> observed. These are really marginal cases that are not relevant for most
> programs.
Cool, thanks.
> Unfortunately, Arrow Functions already auto-capture today, so requiring a
> `use(*)` to enable auto-capture would be a breaking change.
I think there are two things that making this conversation be more
adversial than it could be otherwise:
1. Some people really want implicit auto-capture, while others are
deeply fearful of it. That comes more from the experience people have
from writing/reading different types of code leading them to have
different aesthetic preferences. Trying to persuade people their lived
experience is wrong, is hard.
2. The current situation of having to list all variables is kind of
annoying when it doesn't provide much value e.g. for stuff like:
function getCallback($foo, $bar, $quux)
{
return function($x) use ($foo, $bar, $quux)
{
return $quux($foo, $bar, $x);
}
}
Where the code that returns the closure is trivial having to list out
the full of captured variables does feel tedious, and doesn't provide
any value.
I realise it's annoying when people suggest expanding the scope of an
RFC, however...how would you feel about adding support for use(*) to
the current 'long closures'?
That way, people could choose between:
* Explicit capture of individual variables: function($x) use ($foo,
$bar, $quux) {...}
* Explicit capture of all relevant variables: function($x) use (*) {...}
* Implicit capture of all relevant variables, and fewer letters: fn($x) {...}
People who don't want implicit capture would be able tell their code
quality analysis tools to warn on any use of short closures (or
possibly better, warn when a variable has been captured). People who
do want implicit capture can use the short closures which always have
implicit capture.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [Vote] Pre-vote announcement for Random Extension 5.x
2022年5月31日(火) 18:54 Go Kudo : > Hi internals. > > Although I have explained that due to the global turmoil I will delay > voting on the RFC as long as possible, it is time to start voting on the > RFC in order to get the implementation to full status by the PHP 8.2 > Feature Freeze. > > I apologize for the delay in responding to the points you had already > pointed out. It has been addressed as follows. > > - Random\Engine\PCG64::__construct() now takes an `int|string` $inc as its > second argument > - This makes it fully compatible with the PCG64 original implementation > - Fixed an algorithm implementation error in PCG64 > - Fixed compatibility issues with PHP 8.2 in test cases > - More detailed description in RFC > > Previous discussion thread: https://externals.io/message/117295 > > Voting will begin at 2022-06-14 00:00:00 (UTC). > > https://wiki.php.net/rfc/rng_extension > > Regards, > Go Kudo > Good evening. While refactoring, I found an error in the PCG64 algorithm we are implementing. It should be implemented as pcg64_oneseq_128 (XSL-RR), but currently pcg64_setseq_128 (XSL-RR-RR) is implemented. The RFC also incorrectly states that NumPy implements pcg64_oneseq_128. https://wiki.php.net/rfc/rng_extension The RFC has been corrected for the above. This change removes the int|string $inc argument from RandomEngine\PCG64::__construct(), leaving only int|string|null $seed. Regards, Go Kudo
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Mon, Jun 13, 2022, at 8:36 AM, Rowan Tommins wrote:
> On 13/06/2022 13:57, Arnaud Le Blanc wrote:
>> The proposal is to extend the Arrow Functions syntax so that it allows
>> multiple statements.
>
>
> That's one perspective. The other perspective is that the proposal is to
> extend closure syntax to support automatic capture.
As noted before, this is a distinction without a difference. The proposed
syntax brings in one aspect of short-closures and one aspect of long-closures.
Which you consider it "coming from" as a starting point is, in practice,
irrelevant.
> By the way, the current RFC implies you could write this:
>
> fn() use (&$myRef, $a) { $myRef = $a * $b; }
>
> It's clear that $myRef is captured by reference, and $a by value; but
> what about $b? Is it local to the closure as it would be in a "long"
> closure, or implicitly captured by value as it would be with no "use"
> statement?
>
> It might be best for such mixtures to raise an error.
The RFC already covers that. $b will be auto-captured by value from scope if
it exists. See the "Explicit capture" section and its example.
>> Auto-capture in PHP is by-value. This makes this impossible. It also makes
>> explicit declarations non-necessary and much less useful.
>
>> Live-variable analysis is mentioned in as part of implementation details. It
>> should not be necessary to understand these details to understand the
>> behavior
>> of auto-capture.
>
>
> As noted in my other e-mail, by-value capture can still have side
> effects, so users may still want to ensure that their code is free of
> such side effects.
>
> Currently, the only way to do so is to understand the "implementation
> details" of which variables will be captured, and perhaps add dummy
> statements like "$foo = null;" or "unset($foo);" to make sure of it.
There's two different issues you're raising here that almost seem to be
contradictory.
1. Auto-capture could still over-capture without people realizing it. Whether
this is actually an issue in practice (or would be) is hard to say with
certainty; I'm not sure if it's possible to make an educated guess based on a
top-1000 analysis, so we're all trying to predict the future. Note, however,
that this risk is already present for short-closures, as the capture logic is
the same.
Arguably it's less of an issue only because short-closures are, well, short, so
less likely to reuse variables unintentionally. However, based on my top-1000
survey, even today the vast majority of long-closures are only 2-4 lines long.
I don't believe that makes it 2-4 times more likely, as it's still trivial for
a developer to look at a 2 line closure and say "oh, I'm reusing that variable
name, maybe that's not as clear as it could be."
2. The syntactic indicator that "auto capture will happen". The RFC says "fn".
You're recommending "use(*)". However, changing the indicator syntax would do
nothing to improve point 1. It's just a longer indicator to use the same
logic, especially as it would also require the full "function" word. (Making
fn and function synonyms sounds like it would have a lot more knock-on effects
that feel very out of scope at present.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On 13/06/2022 13:57, Arnaud Le Blanc wrote:
The proposal is to extend the Arrow Functions syntax so that it allows
multiple statements.
That's one perspective. The other perspective is that the proposal is to
extend closure syntax to support automatic capture.
Currently the `use()` syntax co-exists with auto-capture, but we could change
it so that an explicit `use()` list disables auto-capture instead:
```php
fn () use ($a) { } // Would capture $a and disable auto-capture
fn () use () { } // Would capture nothing and disable auto-capture
```
That's an interesting idea. I was coming from the other direction, but
it might make sense I guess.
By the way, the current RFC implies you could write this:
fn() use (&$myRef, $a) { $myRef = $a * $b; }
It's clear that $myRef is captured by reference, and $a by value; but
what about $b? Is it local to the closure as it would be in a "long"
closure, or implicitly captured by value as it would be with no "use"
statement?
It might be best for such mixtures to raise an error.
Unfortunately, Arrow Functions already auto-capture today, so requiring a
`use(*)` to enable auto-capture would be a breaking change.
I'm not suggesting any change to arrow functions, just the ability to
write "use(*)" (or "use(...)") in all the place you can write
"use($foo)" today.
I don't think that introduces any problems, if you think of "fn" as an
alternative spelling of "function", and "=>" as expanding to "use(*) {
return"
I don't find the comparison to a foreach loop very convincing. Loops are
still only accessing variables while the function is running, not saving
them to be used at some indeterminate later time.
Do you have an example where this would be a problem?
I didn't say anything was a problem; I just said that the comparison
didn't make sense, because the scenarios are so different.
Auto-capture in PHP is by-value. This makes this impossible. It also makes
explicit declarations non-necessary and much less useful.
Live-variable analysis is mentioned in as part of implementation details. It
should not be necessary to understand these details to understand the behavior
of auto-capture.
As noted in my other e-mail, by-value capture can still have side
effects, so users may still want to ensure that their code is free of
such side effects.
Currently, the only way to do so is to understand the "implementation
details" of which variables will be captured, and perhaps add dummy
statements like "$foo = null;" or "unset($foo);" to make sure of it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On 13/06/2022 13:29, Arnaud Le Blanc wrote:
Following your comment, I have clarified a few things in the "Auto-capture
semantics" section. This includes a list of way in which these effects can be
observed. These are really marginal cases that are not relevant for most
programs.
I'm not sure I agree that all of these are marginal, or with the way
you've characterised them...
> Note that destructor timing is undefined in PHP, especially when
reference cycles exist.
Outside of reference cycles, which are pretty rare and generally easy to
avoid, PHP's destructors are entirely deterministic. Unlike in fully
garbage-collected languages, you can use a plain object to implement an
"RAII" pattern - e.g. the constructor locks a file and the destructor
unlocks it; or the constructor starts a transaction, and the destructor
rolls it back if not yet committed.
A related case is resource lifetime: file and network handles are
guaranteed to be closed when they go out of scope, and accidentally
taking an extra copy of their "value" can prevent that.
> It ends up capturing the same variables that would have been captured
by a manually curated |use| list.
This slightly muddles two different questions:
1) Given a well-written closure, where all variables are either clearly
local or clearly intended to be captured, does the implementation do a
good job of distinguishing them?
2) Given a badly-written closure, where variables are accidentally
ambiguous, what side-effects might the user experience?
The answer to question 1 seems to be yes, the implementation does a good
job, and that's good news, and thank you for working on it.
That is not the same, however, as saying that question 2 is never
relevant. Consider the following, adapted from an example in the RFC:
$filter = fn ($user) {
if ( $user->id !== -1 ) {
$guest = $repository->findByUserId($user->id);
}
return isset($guest) && in_array($guest->id, $guestsIds);
};
This is not particularly great code, but it works ... unless the parent
scope happens to have a variable named $guest, which will then be bound
to the closure, since there is a path where it is read before being
written. In this case, side effects include:
* The behaviour will change based on the captured value of $guest
* Any resources held by that value will be held until $filter is
destructed, rather than when $guest is destructed
Whether the risk of these side effects is a big problem is up for
debate, but it's wrong to suggest they don't exist.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On samedi 11 juin 2022 23:14:28 CEST Rowan Tommins wrote:
> My main concern is summed up accidentally by your choice of subject line
> for this thread: is the proposal to add *short closure syntax* or is it
> to add *auto-capturing closures*?
The proposal is to extend the Arrow Functions syntax so that it allows
multiple statements. I wanted to give a name to the RFC, so that we could
refer to the feature by that name instead of the longer "auto-capture multi-
statement closures". But the auto-capture behavior is an important aspect we
want to inherit from Arrow Functions.
> As such, I think we need additional features to opt
> back out of capturing, and explicitly mark function- or block-scoped
> variables.
Currently the `use()` syntax co-exists with auto-capture, but we could change
it so that an explicit `use()` list disables auto-capture instead:
```php
fn () use ($a) { } // Would capture $a and disable auto-capture
fn () use () { } // Would capture nothing and disable auto-capture
```
> On the other hand, "auto-capturing" could be seen as a feature in its
> own right; something that users will opt into when it makes sense, while
> continuing to use explicit capture in others. If that is the aim, the
> proposed syntax is decidedly sub-optimal: to a new user, there is no
> obvious reason why "fn" and "function" should imply different semantics,
> or which one is which. A dedicated syntax such as use(*) or use(...)
> would be much clearer. We could even separately propose that "fn" and
> "function" be interchangeable everywhere, allowing combinations such as
> "fn() use(...) { return $x; }" and "function() => $x;"
Unfortunately, Arrow Functions already auto-capture today, so requiring a
`use(*)` to enable auto-capture would be a breaking change.
> I don't find the comparison to a foreach loop very convincing. Loops are
> still only accessing variables while the function is running, not saving
> them to be used at some indeterminate later time.
Do you have an example where this would be a problem?
> This is also where comparison to other languages falls down: most
> languages which capture implicitly for closures also merge scopes
> implicitly at other times - e.g. global variables in functions; instance
> properties in methods; or nested block scopes. Generally they also have
> a way to opt out of those, and mark a variable as local to a function or
> block; PHP does not, because it has always required an opt *in*.
These languages capture/inherit in a read-write fashion. Being able to scope a
variable (opt out of capture) is absolutely necessary otherwise there is only
one scope.
In these languages it is easy to accidentally override/bind a variable from
the parent scope by forgetting a variable declaration.
Auto-capture in PHP is by-value. This makes this impossible. It also makes
explicit declarations non-necessary and much less useful.
> Which leads me back to my constructive suggestion: let's introduce a
> block scoping syntax (e.g. "let $foo;") as a useful feature in its own
> right, before we introduce short closures.
I like this, especially if it also allows to specify a type. However, I don't
think it's needed before this RFC.
> As proposed, users will need to have some idea of what "live variable
> analysis" means, or add dummy assignments, if they want to be sure a
> variable is actually local. With a block scoping keyword, they can mark
> local variables explicitly, as they would in other languages.
Live-variable analysis is mentioned in as part of implementation details. It
should not be necessary to understand these details to understand the behavior
of auto-capture.
I've updated the "Auto-capture semantics" section of the RFC.
Regards,
--
Arnaud Le Blanc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On dimanche 12 juin 2022 20:05:02 CEST Dan Ackroyd wrote: > On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote: > > That RFC didn't fully go to completion due to concerns over the > > performance impact > I don't believe that is an accurate summary. There were subtle issues > in the previous RFC that should have been addressed. Nikita Popov > wrote in https://news-web.php.net/php.internals/114239 > It would produce a better discussion if the RFC document either said > how those issues are resolved, or detail how they are still > limitations on the implementation. > To be clear, I don't fully understand all those issues myself (and I > have just enough knowledge to know to be scared to look at that part > of the engine) but my understanding is that the concerns are not about > just performance, they are deep concerns about the behaviour. Thank you for pointing this out. Nikita was referring to side-effects of capturing too much variables, and suggested to make the capture analysis behavior explicitly unspecified in the RFC so that it could be changed (optimized) later. The new version of the RFC does the optimization. Following your comment, I have clarified a few things in the "Auto-capture semantics" section. This includes a list of way in which these effects can be observed. These are really marginal cases that are not relevant for most programs. Cheers -- Arnaud Le Blanc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On lundi 13 juin 2022 12:28:17 CEST Robert Landers wrote:
> From a maintainer and code review aspect, I prefer the longer syntax
> because it is 100% clear on which variables are being closed over and
> utilized in the anonymous function. fn($x) => $x + $y is pretty clear
> that $y is being pulled in from an outer scope but if you start
> getting into longer ones, it can get non-obvious pretty quickly...
>
> $func = fn($x) {
> $y[] = $x;
> // do some stuff
> return $y;
> }
>
> If $y is pulled from the outside scope, it may or may not be
> intentional but hopefully, it is an array. If anyone uses the name $y
> outside the lambda, this code may subtly break.
This is true for any function that uses the array-append operator on an
undefined variable.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Expand deprecation notice scope for partially supported callables
L.S., I have opened the vote on the "Expand deprecation notice scope for partially supported callables" RFC: https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices The vote will run for two weeks and will close on June 14, 10:30 UTC. The discussion threads about this RFC can be found here: * https://externals.io/message/117720 * https://externals.io/message/117342 If anyone still wants to know a little more about the background of this RFC, you may want to have a listen to Derick's podcast about this RFC: https://phpinternals.news/101 Smile, Juliette Reminder: the vote on this RFC is still open for four more days. If you have voting rights and have an opinion on this, you have four more days to get your vote in. Last call for action - the vote ends in less than 24 hours. Smile, Juliette
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Mon, Jun 13, 2022 at 11:36 AM Arnaud Le Blanc wrote:
>
> On dimanche 12 juin 2022 19:54:06 CEST Mark Baker wrote:
> > Did many of those closures use "pass by reference" in the use clause,
> > because that's one real differentiator between traditional closures and
> > short lambdas. There's also the fact that use values are bound at the
> > point where the closure is defined, not where it's called (if they even
> > exist at all at that point), although that's probably more difficult to
> > determine.
>
> Please note that auto-capture binds variables at function declaration. This is
> the case in Arrow Functions, and is inherited by this RFC.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>From a maintainer and code review aspect, I prefer the longer syntax
because it is 100% clear on which variables are being closed over and
utilized in the anonymous function. fn($x) => $x + $y is pretty clear
that $y is being pulled in from an outer scope but if you start
getting into longer ones, it can get non-obvious pretty quickly...
$func = fn($x) {
$y[] = $x;
// do some stuff
return $y;
}
If $y is pulled from the outside scope, it may or may not be
intentional but hopefully, it is an array. If anyone uses the name $y
outside the lambda, this code may subtly break.
That being said, I'd love this RFC broken into two RFCs, one for
generic auto-capturing and one for multi-line fn functions (just to
reduce some typing when refactoring). There are times when
auto-capturing can be useful for all lambdas, especially when writing
some custom middleware.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Vote] Pre-vote announcement for Random Extension 5.x
2022年6月13日(月) 16:14 Tim Düsterhus : > Hi > > On 6/13/22 04:23, Go Kudo wrote: > > I have created a PoC that allows all internal operations to be performed > in > > 64-bit environments to achieve the same results, although the efficiency > of > > execution in 32-bit environments will be reduced. (Note that > > Randomizer::getInt() with no argument is still incompatible.) > > > > > https://github.com/php/php-src/commit/dbed218bfcd45e713fa3df2c88a4c2efce9f0651 > > > > I believe this is a good solution. The majority of the modern setups > (i.e. the setups that are using PHP 8.2) will likely be 64-bit anyway > and reduced performance on 32-bit is then acceptable. > > Best regards > Tim Düsterhus > Hi Tim Thanks! I have updated the implementation and RFCs. https://wiki.php.net/rfc/rng_extension Voting will open tomorrow (2022-06-14 00:00:00 UTC) as planned. I have reviewed the implementation and would like to clean up the implementation as it is cluttered with past spec changes. This may possibly be too late to start voting, but I do not plan to change the behavior in any way. Best regards, Go Kudo
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On dimanche 12 juin 2022 19:54:06 CEST Mark Baker wrote: > Did many of those closures use "pass by reference" in the use clause, > because that's one real differentiator between traditional closures and > short lambdas. There's also the fact that use values are bound at the > point where the closure is defined, not where it's called (if they even > exist at all at that point), although that's probably more difficult to > determine. Please note that auto-capture binds variables at function declaration. This is the case in Arrow Functions, and is inherited by this RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Vote] Pre-vote announcement for Random Extension 5.x
Hi On 6/13/22 04:23, Go Kudo wrote: I have created a PoC that allows all internal operations to be performed in 64-bit environments to achieve the same results, although the efficiency of execution in 32-bit environments will be reduced. (Note that Randomizer::getInt() with no argument is still incompatible.) https://github.com/php/php-src/commit/dbed218bfcd45e713fa3df2c88a4c2efce9f0651 I believe this is a good solution. The majority of the modern setups (i.e. the setups that are using PHP 8.2) will likely be 64-bit anyway and reduced performance on 32-bit is then acceptable. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
