On Tue, July 28, 2020 at 6:09 PM Mark Randall <marand...@php.net> wrote:
> On 28/07/2020 22:55, Theodore Brown wrote: > > I appreciate the examples. I think there are good reasons not to > > implement these kind of extensions, at least in this form. I'll reply > > to each example below. > > > The problem is your argument comes from a position of... because you > don't like those examples, we shouldn't make accomodation for them or > anything like them in future. > > Adopting such extensions is a matter for a future RFC, and not for > preemptively throwing a spanner in the works. Hi Mark, Future RFCs are as free as they've always been to propose new additions and extensions. Do you think we need to choose a more verbose syntax for every new feature in PHP just to make sure it accommodates keyword flags on the off-chance we may want to add them later? E.g. should we re-vote on the named arguments RFC now and replace the syntax with something designed around adding flags to each argument (e.g. so that function calls could support both an old and new parameter names and be compatible with multiple library versions)? There's good reason to believe that such added complexity is not the best approach, and is very unlikely to be accepted. Preemptively implementing a more verbose syntax with a larger BC break, on the basis of hypothetical extensions which haven't been needed in any other language isn't a good approach to language design, in my view. Anyway, apart from the fact that feature freeze is less than a week away, it seems like voting again to use #[] instead of @@ would violate the voting rules. [1] It hasn't been six months since the last vote, and this proposal is identical to the one declined in the previous RFC. Best regards, Theodore [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
