Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Fri, 2022-07-01 at 16:11 +0200, Hans Henrik Bergan wrote:
> > As far as we are aware, only two languages in widespread use
> > require variables to be explicitly closed over: PHP and C++. All
> > other major languages capture implicitly, as is proposed here.
But do any of them auto-capture by value?
> to be fair to c++, it supports [&] to capture everything, like
> int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
I think that's still explicit
--
Anton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [Under Discussion] Constants in traits
Hello, everyone! I have updated the RFC for constants in traits to reflect the discussion at ML and answer some additional questions, as well as add sections on comparisons to other languages and future scope, and modify some sentences for clarity. https://wiki.php.net/rfc/constants_in_traits If there is no additional discussion, I will open the voting around 2022-07-05 22:00 (UTC) . Thanks! -- Shinji Igarashi 2022年6月22日(水) 6:33 shinji igarashi : > > Hello everyone! > > I'd like to start a discussion on an RFC to allow defining constants in > traits. > https://wiki.php.net/rfc/constants_in_traits > > I'm looking forward to your feedback, including corrections on English > wordings. > > Thanks! > > -- > Shinji Igarashi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension Improvement
2022年6月29日(水) 17:40 Guilliam Xavier : > >> > https://wiki.php.net/rfc/random_extension_improvement > >> > >> I just realized a little thing: in the array_rand() example, for > >> $beforeSingle, it would probably be "more realistic" to omit `, 1` > >> (which is already the default for $num). > >> > >> Note: for `Randomizer::pickArrayKeys(array $array, int $num): array`, > >> it makes sense that $num does *not* have a default value (1 would be > >> "weird" because the method always returns a *list of keys*, and > >> count($array) [via null] would be "useless" because keys are returned > >> *in their original order* [so it would make the method equivalent to > >> array_keys($array) by default]), > >> and that's probably a good thing (it forces to update the call by > >> adding an explicit `, 1` argument and reminds to add a `[0]` or > >> similar on the returned value). > >> > >> An alternative design would be `Randomizer::pickArrayKey(array > >> $array): int|string`, but migrating existing uses with $num != 1 would > >> be harder, so probably not better. > > > > This is certainly a complicated issue. > > > > I proposed the signature `Randomizer::arrayPickKeys(array $array, int > $num): array` because it can be solved with the current PHP sugar syntax > and the default value of $num is 1 despite the name "arrayPickKeys". > > > > However, this is a bit tricky and may not be user-friendly for the > average user. > > > > So, how about adding two methods, `Randomizer::arrayPickKey(array > $array): int|string` and `Randomizer::arrayPickKeys(array $array, int > $num): array`? > > > > This may seem redundant, but it may avoid user confusion. > > Sorry if I wasn't clear: I just suggested to make this little change > in the example: > > ```diff > -$beforeSingle = array_rand(['foo' => 'foo', 'bar' => 'bar', 'baz' => > 'baz'], 1); // (string) foo > +$beforeSingle = array_rand(['foo' => 'foo', 'bar' => 'bar', 'baz' => > 'baz']); // (string) foo > ``` > > to make it more "realistic". > > As concerns the rest (about pickArrayKeys): sorry for the digression, > I was just "thinking out loud", I *don't* want any change there > (first, it makes sense that pickArrayKeys has `int $num` *without* a > default value [even if array_rand has 1]; second, "pickArrayKey" [if > really wanted] is trivial to implement in userland as a wrapper around > pickArrayKeys [but the opposite would not be so], and I don't think > that adding *both* methods to Randomizer is desirable either [better > keep it simple/minimal]). > > Regards, > > -- > Guilliam Xavier > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hi Thank you. That feels true. I will try to keep the RFC as it currently stands. Sorry for the delay in replying. I was a little held up with personal business. I will delay the start of voting by one day. Best regards Go Kudo
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Fri, 1 Jul 2022 at 15:05, Larry Garfield wrote:
>
> The vote for auto-capture closures is now open. It will run until 15 July.
Voting no as:
i) changes in the implementation need more than 1.5 hours discussion
between that change and the voting opening.
ii) The inconsistency of capturing rules between this RFC and arrow
functions are "not obviously" the correct choice. And definitely need
more than 90 minutes of thinking about.
iii) Some of the phrases in the RFC are still just not true.
"Capture is by-value, no unintended side-effects"
"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."
They are true for scalar values, but not for objects.
RFCs need to be written clearly so that people don't get the wrong
impression if the don't read every single word.
btw for my concerns about object capturing and RAII, the manual could
probably say something like:
> If you want to ensure an object is captured you can either assign it to
> itself:
>
> $foo = $foo;
>
> Or create an empty function:
>
> function ensure_variables_stays_alive(mixed $variable)
> {
>/* function is intentionally blank */
> }
>
> and call that function with the variable you want to stay alive inside the
> closure.
But again, this is "not obviously" the correct choice.
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
>As far as we are aware, only two languages in widespread use require
variables to be explicitly closed over: PHP and C++. All other major
languages capture implicitly, as is proposed here.
to be fair to c++, it supports [&] to capture everything, like
int a=1,b=2,c=3;[&]()->void{std::cout << a << b << c;}();
On Fri, 1 Jul 2022 at 16:05, Larry Garfield wrote:
> Greetings, Internalians.
>
> The vote for auto-capture closures is now open. It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
[PHP-DEV] [RFC][Vote] Auto-capture closures
Greetings, Internalians. The vote for auto-capture closures is now open. It will run until 15 July. https://wiki.php.net/rfc/auto-capture-closure -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC][Voting] Fetch properties of enums in const expressions
Hi everyone I opened voting for the "Fetch properties of enums in const expressions" RFC. https://wiki.php.net/rfc/fetch_property_in_const_expressions Voting closes on 2022-07-15. Ilija -- 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 Björn, On Wed, Jun 29, 2022 at 8:09 PM Björn Larsson via internals < internals@lists.php.net> wrote: > Would it be an option to include a "Future scope" with the features: > - Explicit capture that list only the variables to be captured by value > or reference, nothing else. > - Extending the traditional anonymous function with use(*) for capturing > everything. > > Anyway, hope this passes for PHP 8.2! > Thank you for the suggestion. The RFC now includes a Future Scope section. The extension of traditional anonymous functions is discussed separately in the "Alternative implementations" section. Regards,
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Rowan, Since this still has a small chance of breaking existing code, we preferred to exclude arrow functions from this change, for now. We have added this in Future Scope. This is something we could do in a follow-up RFC. Regards,
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Guilliam, Thank you for noticing. The PR is now fully in sync with the RFC (no arrow function changes, no explicit use support). The RFC also now clarifies that arrow functions are not changed by the RFC.
Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
Hi On 7/1/22 12:07, Rowan Tommins wrote: My concern is rather the opposite: if it is not obvious *to someone writing PHP code* how the API should be used, there is a higher chance of them using it incorrectly, and introducing errors. A good example of this mindset is the password_* functions: they do not expose the options of underlying implementations, they present an easy-to-use *opinionated* set of behaviours, that solves a common use case for their audience. They allow users to "fall into the pit of success", because the easy thing is also the correct thing. The difference to me is that "curl" is a well-established library with an existing API. By faithfully representing the original API (e.g. the naming of the options/flags), I can leverage the existing documentation or Stack Overflow Q to learn what exactly a specific option does. This would be different for an "url" or "http" or "uri" extension. That one might use cURL currently and might use https://github.com/uriparser/uriparser in a future version if there are good arguments to change the underlying library. It would just guarantee you that it can process URIs correctly according to whatever API one creates. The password_* family uses such a generic term: "password". It does not pretend to be "libargon2". In other words: If it says "curl" on the box, then I expect to have "curl" within the box. However, to me at least, it's not entirely clear who the target audience for this API is, what tasks it should be making easy, and what correct usage looks like. Just providing a bunch of functions, in whatever form, doesn't provide security unless users can understand how to use them securely. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
On Thu, 30 Jun 2022 at 23:21, Levi Morrison via internals < internals@lists.php.net> wrote: > On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron > wrote: > > One of the goal of this API is to tighten a problematic vulnerable area > > for applications where the URL parser library would believe one thing > > and libcurl another. This could and has sometimes led to security > > problems. > > Designing another API on top of what libcurl provides _could make the > problem worse_. My concern is rather the opposite: if it is not obvious *to someone writing PHP code* how the API should be used, there is a higher chance of them using it incorrectly, and introducing errors. A good example of this mindset is the password_* functions: they do not expose the options of underlying implementations, they present an easy-to-use *opinionated* set of behaviours, that solves a common use case for their audience. They allow users to "fall into the pit of success", because the easy thing is also the correct thing. However, to me at least, it's not entirely clear who the target audience for this API is, what tasks it should be making easy, and what correct usage looks like. Just providing a bunch of functions, in whatever form, doesn't provide security unless users can understand how to use them securely. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Thu, Jun 30, 2022 at 7:37 PM Arnaud Le Blanc wrote: > > On jeudi 30 juin 2022 18:29:44 CEST Guilliam Xavier wrote: > > Ah? Sorry, I had interpreted > > https://github.com/php/php-src/pull/8330/files#diff-85701127596aca0e597bd796 > > 1b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 as "capture the > > *minimal* set of variables for *both* arrow functions and short closures", > > but I was wrong? > > No, you are right, the PR changes arrow functions too. But in the RFC we > decided to not touch the arrow functions for now. Ah, I see that you have updated the PR indeed: https://github.com/php/php-src/pull/8330/commits/5bb0a1c8d032666079db5dab94b4b22b2afa9dac (and thanks for the test). PS: so the link I gave before is now outdated ^^' I should have given https://github.com/php/php-src/pull/8330/commits/9dec265adba44dcf9d2cadc05dd5ad842fc4ae66#diff-85701127596aca0e597bd7961b5d59cdde4f6bb3e2a109a22be859ab7568b4d2R7318-R7320 -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
