said feedback should they choose to acknowledge it.
And in general, the wider PHP community does not pay attention to RFCs
until/unless they come up for a vote.
Admonishing people for providing unexpected or negative feedback will
have a chilling effect for future RFC attempts, as it's much easier to
just silently vote no than to be attacked simply for providing a
dissenting opinion at an inconvenient time.
- Mark
ness get that safety, while avoiding a
potentially costly and onerous upgrade for the community.
- Mark
troduced #[Override]?
#[Nonvariadic]
function foo () {}
foo(42); // warning: foo() expects exactly 0 arguments, 1 given
I think the intent would be clearer and it would avoid introducing a new syntax.
- Mark
Hello,
In the past there was a List-Id header. This seems to be missing now. Is it
expected to be added again? Else I will update my mail rules.
Kind regards, Mark
> -Original Message-
> From: Derick Rethans
> Sent: Wednesday, February 14, 2024 16:16
> To: Internals@l
uding the pre-release ones.
- Mark Trapp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
different creators than their supertypes. In addition, omitting cre=
ators makes it easy for a type to have multiple implementations, allows new=
creators to be added later, and re ects common usage: for example, Java in=
terfaces and virtual types provide no way for users to create objects of th=
e type.
(Creators is Liskov's word for constructors, which they later define
in the paper.)
Hope that helps.
- Mark Trapp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t easy for a type to have multiple implementations, allows
> new creators to be added later, and re ects common usage: for example, Java
> interfaces and virtual types provide no way for users to create objects of
> the type.
(Creators is Liskov's word for constructors, which they later define
in the paper.)
Hope that helps.
- Mark Trapp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/function.round.php
My implementation: https://github.com/php/php-src/pull/11741
I'm not sure if such minor improvement requires RFC, but as someone may
have some concerns I create this thread to get your feedback.
Kind regards,
Jorg
--
Mark Baker
--
PHP Internals - PHP Runtime Development
constants like
\MyNamespace\MyFunction::function?
If there is value, how would that tie in with referencing them as
Callables in callback functions?
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
example.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
sions and only then the feature is completely
removed or made a full-on error"
I do wish that this was always the case!
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 10/04/2023 21:01, Hans Henrik Bergan wrote:
several PHP versions will be maintained for 10 years by third-party vendors.
PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com
maintains PHP5.6 with multiple customers paying 6000€/year for 5.6
maintenance.
Canonical intends
ho can't develop in greenfield environments using the
latest shiny, or that it should just be a simple upgrade step from last
version to current release... that's the equivalent of having unit tests
that only test the happy path.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing Lis
version to
the next. Library writers don't have that luxury: their codebase
normally has to work with a range of PHP versions including the latest
release; and any fixes that are made for the latest release still have
to work with older PHP versions, which can take significantly more
effort to
s some of
the tools that we use for developing and testing.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
. var_dump(range('A1', 'C5')) which returns
a purely alpha array 'A' to 'C'; or var_dump(range('3c', '5e')) which
returns numeric (3, 4, 5); or var_dump(range('1', '1e2')) which treates
`1e2` as scientific and returns 1..100.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Ma
On 29/03/2023 16:43, Mark Baker wrote:
On 29/03/2023 16:31, Davey Shafik wrote:
On Mar 29, 2023, at 06:56, Rowan Tommins
wrote:
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius
wrote:
Ok so I am trying to find the argumentation here:
This is by design.
The point of enums
That would make a lot of sense, and I was just having similar thoughts
myself.
ApiErrors isn't the same enum, or an extension of HttpErrors: it's a new
Enum, but it does include all HttpErrors cases (and methods) without the
need to duplicate code, and any new cases that are subsequently adde
= 'php';
int $pos = strpos($mystring, $findme); // $pos can be an integer or false
or when a type can legitimately change
int $result = PHP_MAX_INT;
++$i; // $i is now a float
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net
Dan,
On Sat, Feb 4, 2023 at 8:34 AM Dan Ackroyd wrote:
> Hi Mark,
>
> On Sat, 4 Feb 2023 at 00:22, Mark Niebergall
> wrote:
> >
> > This is also a bigger policy question for other seemingly-abandoned
> > RFCs. If it is agreed that a new RFC should be created in
Benas,
On Sun, Feb 5, 2023 at 9:29 AM Benas IML wrote:
> [copy of the email that I have accidentally sent to Mark individually]
>
> Hey,
>
> As much as I appreciate your enthusiasm and ideas, adding your name on
> my original RFC and editing its contents without my approval i
Máté, Benas, Internals,
On Fri, Feb 3, 2023 at 7:34 AM Máté Kocsis wrote:
> Hi Alexandru, Mark,
>
>
> > 1. Why is object type not supported? I can't see a real reason and also
> > there is no explanation why.
> >
>
> Sorry for this, mentioning object as
yncracies of alphanumeric
strings could be resolved by not trying to cast them as a numeric value
before increment/decrement; but by treating them consistently as
strings? It would resolve the discrepancy with "5d9"; although not with
"0xf9".
--
Mark Baker
--
PHP Internals - PHP R
rete class.
- Mark Niebergall
On Tue, Jan 31, 2023 at 5:55 PM Ondřej Mirtes wrote:
> I fully support this RFC. PHPStan added support for PHPDoc types in class
> constants some time ago - it’s useful to rely on the same constant type
> even in subclasses when accessing them via
le more than a syntactic sugar for numeric values
only; I'm afraid I don't see that as a benefit; but as a retrograde
step, and not the same as making ++ and -- consistent.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that deprecation will have a very direct and
adverse affect on my work.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
operators are used.
$a = PHP_INT_MAX;
++$a;
or
$a = '10';
++$a;
both change the datatype of $a; which isn't documented behaviour either.
--
Mark Baker
it was being used on (SA tools won't
necessarily help with that); and when looping over Excel rows and
columns it would seem strange allowing the ++ operator for rows, but
having to use a function call for columns when all previous code also
used ++.
--
Mark Baker
--
PHP Internals - PHP Runtime
en a block is alpha characters, then the increment
behaviour matches "Excel's bijective base-26".
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
aning; and also to provide better code readability.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Thanks for the reply Ben, once I get home I’ll send what I did exactly.
Sent from my iPad
> On Sep 17, 2022, at 11:42 AM, Ben Ramsey wrote:
>
>
>>
>>> On Sep 16, 2022, at 20:27, Mark Tomlin wrote:
>>>
>> To the release managers of PHP, ple
and thank you.
--
Thank you for your time,
Mark 'Dygear' Tomlin;
, not to mention the potential length of property definitions
--
Mark Baker
_
|. \ \-3
|_J_/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
components rather than something specific to Curl.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 22/06/2022 05:38, Pierrick Charron wrote:
Feel free to give any feedback, concern or support :-)
This should preferably be namespaced.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
called (if they even
exist at all at that point), although that's probably more difficult to
determine.
--
Mark Baker
_
|. \ \-3
|_J_/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e, two existing open/close settings
and two new combinations, the first you explain
but also
What should PHP do when it encounters this combination of
opening/closing tags?
--
Mark Baker
_
|. \ \-3
|_J_/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
--
PHP Internals - PHP R
On 28/05/2022 03:36, Craig Francis wrote:
In this case, two of my clients are considering the cost of modifying their code (by adding a load of `?? ''` everywhere), and they would rather avoid that (time consuming, and makes their code more complicated).
Alternatively, they may wish to
On 28/05/2022 10:53, Aaron Junker wrote:
When you have feedback to a specific point of the RFC, please use the
corresponding number used in the RFC.
To point 1, there was a time I was thinking about implementing a system
ourselves (I was working on website prototypes at the time).
That
On 20/05/2022 10:05, Ilija Tovilo wrote:
So unless there are concerns I will amend that in the RFC.
Erroring it out makes sense to me.
As we don't include any target version specification in PHP files, the
safest bet it so prevent the silent change from potentially leaking
through the
On 18/05/2022 16:23, Craig Francis wrote:
If the Session ID continued to work as the Identifier, but the client was given
the Session ID and a Random Key (could be concatenated together for the
cookie)... that means the Random Key would not be stored on the server, and
could protect the
On 17/05/2022 21:36, David CARLIER wrote:
I wanted a more general but early feedback on the idea itself
https://github.com/php/php-src/pull/3759
The same question that has already been asked on github:
What is the motivation? What is it meant to achieve?
--
PHP Internals - PHP Runtime
On 08/05/2022 11:48, Jordan LeDoux wrote:
This is not the case with null. If you use the unset() function on a
variable for example, it will var_dump as null *and* it will pass an
is_null() check *and* it will pass a $var === null *and* it will return
false for an isset() check. Null loses these
On 21/04/2022 22:45, Mark Randall wrote:
I have now opened voting on Undefined Property Error Promotion.
https://wiki.php.net/rfc/undefined_property_error_promotion
The vote has concluded.
The RFC has been passed with 31 votes (86%) in favour, 5 against.
--
Mark Randall
--
PHP Internals
On 25/04/2022 12:51, Christoph M. Becker wrote:
Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases[2].
I could potentially be interested in helping out with this,
On 26/04/2022 10:54, Andreas Leathley wrote:
Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true.
If we could get rid of "0" being false, that alone would be a huge
benefit for the language in the long run.
I know why it exists, but
On 22/04/2022 21:30, Rowan Tommins wrote:
Do you not have even a little bit of hope that we could make that less
confusing, since we're breaking everyone's old code anyway?
I seem to remember we had a discussion years ago about deleting unset on
properties, but it was being used for a very
On 22/04/2022 14:42, Rowan Tommins wrote:
As with your previous RFC, I approve of this in principle, but am
frustrated how little time has been spent considering the edge cases, such
as the ones I mentioned here: https://externals.io/message/117487#117487
Accessing an unset property, which
Internals,
I have now opened voting on Undefined Property Error Promotion.
https://wiki.php.net/rfc/undefined_property_error_promotion
Voting ends 2022-05-05
Summary:
This RFC seeks to prevent execution continuing if the user has accessed
an undefined property without specifying that it was
Down the line this might allow us to fix up arrays as well, but that's a
question for a different RFC.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
he
person raising these concerns is too often shouted down for raising "a
storm in a teacup".
--
Mark Baker
_
|. \ \-3
|_J_/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 06/04/2022 17:34, Marco Pivetta wrote:
Perhaps worth mentioning that magic methods keep working?
Good call.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
removed it.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Guilliam,
On Wed, Mar 30, 2022 at 7:50 AM Guilliam Xavier
wrote:
> Hi Mark,
>
> I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with
>>>> more details and examples from this thread, and updated the RFC status
>>>> to
>>>> Unde
Alex,
On Wed, Mar 30, 2022 at 7:47 AM Alexandru Pătrănescu
wrote:
> Hey Mark,
>
> On Wed, Mar 30, 2022 at 4:01 PM Mark Niebergall
> wrote:
>
>> Alex,
>>
>> On Tue, Mar 29, 2022 at 10:35 PM Alexandru Pătrănescu
>> wrote:
>>
>>> Hey
Alex,
On Tue, Mar 29, 2022 at 10:35 PM Alexandru Pătrănescu
wrote:
> Hey Mark,
>
>
> On Wed, Mar 30, 2022 at 6:03 AM Mark Niebergall
> wrote:
>
>>
>> I have updated the RFC https://wiki.php.net/rfc/typed_class_constants
>> with
>> more details and exam
On Mon, Mar 28, 2022 at 6:54 AM Guilliam Xavier
wrote:
> Constants are not abstract in an interface - they must be assigned a
>> value. Only classes and methods can be abstract. Within an abstract class
>> it is not valid to have an abstract property. Properties can be defined
>> `protected int
On 14/03/2022 17:18, Mark Randall wrote:
I have started the vote for promoting undefined variable access to throw
an Error exception.
The vote will run for 2 weeks until March 28th 2022.
https://wiki.php.net/rfc/undefined_variable_error_promotion
The RFC has passed with 33 votes (80
On Fri, Mar 25, 2022 at 10:55 AM Guilliam Xavier
wrote:
> I intentionally left `abstract` out of `public const bool CAN_FLY;` in the
>> `abstract class` for consistency with the implementation with `interface`,
>> which would also have to be `public const bool CAN_FLY;`. Currently
>> `abstract`
in PHP for ~17 years.
Plans - I'm picking up the typed constants RFC where it was left off,
planning to create a new RFC for this go around. I have a few other future
ideas I've also been tinkering with and plan to create several other RFCs
in the future.
Username: mbniebergall
Thanks,
Mark
Guilliam,
On Fri, Mar 25, 2022 at 6:35 AM Guilliam Xavier
wrote:
> Hi Mark,
>
> On Wed, Mar 23, 2022 at 11:55 PM Mark Niebergall
> wrote:
>
>> (...)
>>
>> Another example I often see in my projects could be used with a similar
>> example:
>>
>
On Thu, Mar 24, 2022 at 1:00 PM Rowan Tommins
wrote:
> On 23/03/2022 18:54, Mark Niebergall wrote:
> > The next phase of work with different RFC would take
> > this further with const inheritance, where const type must match.
>
>
> I'm not sure it makes much sense to
Pierre,
On Thu, Mar 24, 2022 at 9:20 AM Pierre wrote:
> Le 24/03/2022 à 16:06, Mark Niebergall a écrit :
> > So you are correct, the const value does have a value that has a type,
> but
> > there is no way to enforce which type the value is or to use const with
> > in
Pierre,
On Thu, Mar 24, 2022 at 1:04 AM Pierre wrote:
> Le 23/03/2022 à 23:10, Larry Garfield a écrit :
> > Is there a benefit to it other than "well everything else has types now,
> so..."? Even if it's esoteric, like in reflection-based meta programming?
> (I've been dabbling too much in
On Wed, Mar 23, 2022 at 4:10 PM Larry Garfield
wrote:
> On Wed, Mar 23, 2022, at 1:54 PM, Mark Niebergall wrote:
> > Hello All,
> >
> > In June 2020, Benas Seliuginas emailed this list (
> > https://externals.io/message/110755#110755) to gauge interest in typed
&
inheritance, where const type must match.
- Mark
On 16/03/2022 09:17, Christian Schneider wrote:
Maybe we should ask ourselves the question: Why would the entire package be
blocked? Just because it is too big or maybe there *are* subtleties which have
not been properly resolved?
It's politics and the practicalities of getting things done.
On 15/03/2022 23:02, Patrick ALLAERT wrote:
I am not against the fact this warning becomes an error per se. I am just
not very fan of cherry-picking an individual kind of problem (read:
notice/warning/error/...) and changing it without a more global frame.
I think we should try to hit all of
On 15/03/2022 19:32, Sara Golemon wrote:
What I'm hearing is that we also need an RFC for promoting 'Undefined
index...' warnings to Errors as well.
We do. If it would pass or not is another matter, it would need someone
braver than I to take it up.
I think there's some other engine
nto this release, I would like to see some risk
assessment undertaken on the affect that each deprecation RFC will have,
with some real figures for the number of repositories that require work
to prepare them for the release.
--
Mark Baker
_
|. \ \-3
|_J_/ PHP |
|| | __ |
||
I have started the vote for promoting undefined variable access to throw
an Error exception.
The vote will run for 2 weeks until March 28th 2022.
https://wiki.php.net/rfc/undefined_variable_error_promotion
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On 07/03/2022 12:56, Thomas Krüger wrote:
Or if it has nothing to do with performance, why not including
everything from PECL into PHP core, so PHP could offer out-of-the-box
more and more features for developers?
PECL packages get to maintain their own release schedule, unlike PHP
which
with their coding standards.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 28/02/2022 01:46, Craig Francis wrote:
Personally I think `strict_types=1` is fine for my code, but I would never
want to force that style on everyone, because doing so would be fairly
hostile for a language that's popular and well known for being easy to
use/learn.
Magically coercing
On 27/02/2022 09:12, Robert Landers wrote:
I'd also venture that this warning has caused more harm than good, in that
writing "$var['something'] ?? null" is second nature when writing new
code, even if there is practically no chance for a non-existent key.
Using null coalesce should only be
OST['name'] ?? 'Default Name') ?: 'Default Name';
Should be:
$name = ($_POST['name'] ?? null) ?: 'Default Name')
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 26/02/2022 09:09, Robert Landers wrote:
I'd like to propose and implement an RFC that would consider dropping the
warning if and only if array access is the only test in ternary and short
ternary (?:) operations but first I'd like to start a discussion to see if
it is worth pursuing. I'd like
m, without
requiring an opt-out.
I must therefore assume you consider the use of undefined variables to
be a legitimate coding style, and that's fine if that is your position.
This RFC boils down to internals deciding, as a group, that it isn't one
we want to support in future.
Mark Randa
On 23/02/2022 19:32, Rowan Tommins wrote
I think that wording change should be part of the proposed change in the
RFC. Otherwise, a lot of people simply won't know the decision to remove
it has been made and will be surprised when 9.0 comes around.
It is already part of the RFC within the
doing it.
It may be that in 8.2 if this RFC passes that message will change to
include "This will throw an error in PHP 9", but giving multiple
messages for it is not beneficial IMO.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://w
.
If there's am existing formal definition someone wishes to contribute,
I'd be happy to update it.
One thing maybe worth mentioning is that while most operators such as
++, +=, .= etc will be covered by this change, $undefined[] = 1; will
not be.
Mark Randall
--
PHP Internals - PHP
On 22/02/2022 09:15, Nicolas Grekas wrote:
I very much call for an implementation to be provided before starting any
vote on the topic btw.
The RFC states on its first line that accessing an undefined variable
emits an E_WARNING. If it does not currently emit an E_WARNING then it
is out of
On 21/02/2022 10:29, Nicolas BADIA wrote:
and I don’t find the code more readable. Here are some examples of changes:
The example changes you provide are what many people here would
recommend as good practice to improve the context and safety your code
provides.
Anyone looking at that
that means it
will be affected by this proposal.
It is intended to be affected by this proposal.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
at all is because an undefined variable read
falls back to null, and the increment operator is hardcoded to treat
null++ as 1.
That's why if you do this:
$x = $foo++;
var_dump($x);
You get:
Warning: Undefined variable $foo in on line 3
NULL
Mark Randall
--
PHP Internals - PHP Runtime Devel
other error promotions forward, potentially in
collaboration with other developers, but as this is the biggest change,
and the most likely to attract a large number of comments, I thought it
deserving of a standalone RFC.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
that, you may instead wish to stay
on an older version that hax more lax behaviour, and purchase LTS from
the likes of Zend.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/02/2022 13:49, Robin Chalas wrote:
What do you think?
It sounds like you need to wrap get_debug_type rather than introduce a
magic method into core to account for framework oddities.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
On 07/02/2022 15:34, Craig Francis wrote:
So are you suggesting that all the frameworks should change their default
to an empty string? or every single project should update every use of
these input functions to always override this default, or cast the received
value to always be a string? all
ework worth its salt
will also have the option to provide a default value other than null
when the value is not provided.
It is the responsibility of the user to make use of this functionality
to provide the correct type for what the soon-to-be-called function is
expecting.
Mark Randall
--
sucks that it was ever allowed in the first place.
PHP has a long history of making descisions to try to make things 'just
work', and if history teaches us anything, its that we inevitably come
to regret these descisions down the line.
Mark Randall
--
PHP Internals - PHP Runtime Development Mail
On 29/01/2022 16:33, Christian Schneider wrote:
If a static analyzer manages to catch it at development time then that is a lot
better.
Of course it's better, but you wouldn't argue that a car doesn't need
airbags because you've tested that the breaks work.
Defense in depth.
Our ecosystem
On 27/01/2022 22:09, Larry Garfield wrote:
I am not sure what additional value is gained by making the scream even louder.
For us to make something an exception at engine level, is to stop
execution on the grounds that the engine no longer considers it safe to
continue.
That might be
lax in this regard.
We should be aiming to provide a reasonably safe experience out the box.
That you're manually patching PHP to change official behaviour (which
was passed by RFC) puts your individual use case well outside of what
should be considered when voting.
Mark Randall
--
PHP
n in PHP 9, but I am not proposing
it with this batch of updates.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
decide what route to take
with regards to bringing RFCs to vote.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/redefine_constants_exception_strawpoll
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/12/2021 05:22, André Hänsel wrote:
This is very useful because I can add an optional parameter to a function
and prevent users of my function from using the parameter in a positional
way. This way I don't have to make a compatibility promise to never change
the position of this parameter.
.
As this RFC focuses heavily on array_columns, including all of the
examples and the PR, I would encourage the author to consider an RFC
specifically for array_column_group.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 04/12/2021 14:21, Marco Pivetta wrote:
Gonna vote `no` on this: please design new/dedicated functions, rather than
expanding optional parameters.
I would vote no for the same reason.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
1 - 100 of 463 matches
Mail list logo
