will need to be modified to
be compatible with those measures.
To do otherwise would be entirely unethical.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 23/07/2021 10:58, Nicolas Grekas wrote:
Hi everyone,
I wrote everything down about the reasons why here:
https://wiki.php.net/rfc/nullable_intersection_types
IMO we should require brackets and forbid not using them when combining
unions and intersections.
These types are already going
. It would
be nice to just be able to ask phpinfo where these config files are.
--
Thank you for your time,
Mark 'Dygear' Tomlin;
I really think that the implicit `match (true) {` is an easily understood
behavior.
On Fri, Jun 18, 2021 at 11:04 AM Guilliam Xavier
wrote:
> On Fri, Jun 18, 2021 at 4:24 PM Larry Garfield
> wrote:
>
> > On Thu, Jun 17, 2021, at 1:49 PM, Mark Tomlin wrote:
> > > Ple
ry vote on the previous RFC was 80% in favor
> of it.
>
> (And I still think the argument is stronger if you include a comparison to
> ternary assignment, but that doesn't affect implementation.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Thank you for your time,
Mark 'Dygear' Tomlin;
On 06/06/2021 14:00, Ben Morss via internals wrote:
Thank you for these comments!
Perhaps it would make sense to, at some point, create a followup proposal
to namespace the entire gd extension - so that all gd functions would be in
the namespace? I'd leave it to others to determine whether this
nding to a variable of type false will throw a
deprecation error"
You might want to clarify this language, throwing an error is understood
to have a specific meaning in PHP, and it's not what it's doing here.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
, but but I do get the feeling that, as we can future proof it
for effectively zero cost, we should.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
traditionally be a by-ref, repeating
the previous lookup with FETCH_DIM_W?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 15/05/2021 01:00, Larry Garfield wrote:
I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a
On 14/05/2021 22:48, Aaron Piotrowski wrote:
I think it’s reasonable to allow passing more arguments to a partial since
user-defined functions and closures allow this without error.
But only userland functions, a relic from when func_get_args was the
only way to handle varaible numbers of
}
Equally it matches the syntax for unpacking into arguments:
$a = foo($a, ...$b);
Passing more arguments than the partial defines would result in an
argument count error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/05/2021 09:05, Stanislav Malyshev wrote:
I don't see how we could "just move" if all our bug handling would be
wired into Github. I can easily see how we could move a repo to any
provider that supports git - git is a generic platform, Github is just a
frontend. But there's no alternative
On 08/04/2021 19:38, Stanislav Malyshev wrote:
I think it's just because nobody has focused attention to it. As you
see, once it was focused, it has happened.
This is usually referred to as shutting the stable door after the horse
has bolted.
--
PHP Internals - PHP Runtime Development
On 15/03/2021 17:41, Mark Randall wrote:
I would like to propose the addition of a new mechanism of autoloading
classes - a classmap that will be consulted prior to checking the
spl_autoload_register'd callbacks.
https://wiki.php.net/rfc/autoload_classmap
Does anyone else have any more
On 27/03/2021 16:52, Abdul Haq Sheikh wrote:
- On Index.php, php will automatically include 'vendor/autoload.php'
because the vendor directory exists.
- On Test.php, php will automatically include 'vendor/autoload.php'
because the vendor directory exists.
- On Classes/test2.php, since file is
On 25/03/2021 13:54, Olle Härstedt wrote:
JS does not support "definitely local". No language does, AFAIK.
Unless you count value types.
We were both refering to block-level variables, which most languages do.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 25/03/2021 09:28, Rowan Tommins wrote:
That's not quite what I meant. I meant that you can't say "capture by
default, but this variable is definitely local".
I think if there's one argument against, this would be it, but IMHO it
is a weakness in PHP as a whole.
The solution would be
auto capture is a solid +1.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
).
>>
I appreciate this is a small amount. If internals feels the additional
code is not worth it for such a small gain, I have no issue at all with
the RFC being rejected.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.p
% of an extremely common
operation is worth the few dozen lines of code required.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
is lowercase, the value,
the path name, IS case sensitive.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 15/03/2021 22:18, Levi Morrison via internals wrote:
Like any other case insensitive symbol PHP works with that comes from
userland, I would lower it in the engine's side of things. I would not
push the lowercase requirement on the API.
That was the first design, however it required
On 15/03/2021 17:59, Levi Morrison via internals wrote:
IMO, these should be the defined case of the class, or we should be
insensitive about it. It's one thing that our symbols are case
insensitive; it is wholly another to _require_ it for this feature by
requiring lowercase names. I assume
Hi Internals,
I would like to propose the addition of a new mechanism of autoloading
classes - a classmap that will be consulted prior to checking the
spl_autoload_register'd callbacks.
https://wiki.php.net/rfc/autoload_classmap
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime
On 18/02/2021 03:37, Mark Randall wrote:
Long ago, PHP had a similar feature called Magic Quotes.
My apologies, I had only that top paragraph visible in my preview and
responded to entirely the wrong part of your post :-(
--
PHP Internals - PHP Runtime Development Mailing List
Quotes.
It is now universally considered to be among the worst and most damaging
features that PHP ever introduced.
There is no apetite to reintroduce such a thing.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
a significantly bigger
and more beneficial impact on userland.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s together.
If SPL\ is to exist (and personally I think SPL is so cancerous, it
shouldn't) then IMO it must absolutely be SPL\iterators.
Without that all we've done is swap one problem for another.
The idea of putting data structures next to generic iterator helpers is,
quite frankly, nuts.
Ma
On 08/02/2021 15:14, Kalle Sommer Nielsen wrote:
Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals
:
- I do not like the chosen namespace. This is not as important as the
previous point, but still factored into my decision as we are still
very early in choosing namespaces for
candidates for
\PHP\SubNS rather than \Ext\SubNS
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t avoids the need for two methods, just provide the one that throws and
use shorthand to assign a null if it throws.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 06/01/2021 14:57, Nikita Popov wrote:
Once you introduce an
additional meaningful namespace in the form of SPL\iterable\any, you are
better off either dropping the SPL part and arriving at iterable\any, or
replacing SPL with something more sensible and arriving at PHP\iterable\any.
On 19/12/2020 20:24, tyson andre wrote:
Hi internals,
I've created a straw poll for the naming pattern to use for `*any()` and
`*all()` on iterables.
https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
These functions make sense. However I think we need to give renewed
consideration to:
On 11/11/2020 20:20, David Rodrigues wrote:
If yes, what is the reason for requiring it? Why it can't be the default
behavior (or maybe, the unique behavior).
There was some discussion around the idea of adding language editions to
PHP for 8.0, however the pandemic resulted in to the
On 01/09/2020 16:05, Levi Morrison via internals wrote:
Anyway, the key point I'm making is that I think a larger RFC has a
better shot of passing if we want to namespace it.
Try as we might 4 of us working together couldn't get namespaces
accepted. I got the feeling that there seems to be an
would be if people were using external
code to do pre-processor like operations such as using #start and #end
as quasi-tags.
Ideally, if we pass #[ ] we would deprecate # in the same version and
put it on the fast-track to removal, but that would require an
additional vote.
Mark Randall
,
#[Inject] Bar $bar,
string $value
) {
...
}
}
$container->factories(Foo::class)("value");
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
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.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
happen.
What is clear is we've got to support Attributes for 20, 30 years, and
we should leave the door open for easier and cleaner syntax additions if
there's no compelling reason not to.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
On 26/07/2020 17:24, Larry Garfield wrote:
The vote on the PHP namespace policy is now open:
https://wiki.php.net/rfc/php_namespace_policy
Thanks to Larry for putting in a lot of effort with this RFC.
I would like to think this RFC provides a solution to a legitimate
long-term problem.
1.
ected Attr) but at which point why not
just use a mechanism that supports it out of the box?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 23/07/2020 08:02, Côme Chilliet wrote:
To be clear, is there anyone who voted for @@ and changed his mind based on new
information?
Please see the initial discussion here:
https://externals.io/message/110568#111038
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
+ years of supporting a syntax that we
already have strong reservations about before it's even out the door.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t; the result could turn out differently. The
only way to know is to take another vote.
Yes we do - it was a ranked choice vote where voters selected their
first, second and third preferences.
If @@ is eliminated, the second choice of all those who voted for it as
their first choice is alrea
there are perfectly good
alternatives?
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 20/07/2020 16:58, Michael Wallner wrote:
Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s). As a project we rightfully own the root namespace, and
putting everything beneath PHP just doesn't make any sense to me.
You cannot just "own" the root namespace
On 17/07/2020 09:23, Lester Caine wrote:
So does that also apply to \Ext? Currently the selection of extensions
is flexible and most distributions allow the easy repackaging of just
what is available. Creating a 'core' set off extensions under \PHP is
essentially saying 'you will make these
On 17/07/2020 04:49, Levi Morrison via internals wrote:
I don't care to debate it. I will just vote no.
Fair enough, however the point of the internals mailing list and
discussion period is to debate the RFCs :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
s location. The
purpose of that one level is to avoid extensions trampling into multiple
userspace naming areas.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 16/07/2020 15:43, Nikita Popov wrote
I haven't backported any deprecation warnings to 7.4. Adding deprecations
to released versions is a hard no-go.
My apologies.
I'd got my wires crossed with seeing
https://github.com/php/php-src/pull/3917 appear on the PRs.
--
PHP Internals - PHP
ges coming in 8.0?
So it's not really impossible... it just takes the will to do it.
We can keep making small tweeks trying to make it better, or we can just
do the "proper" thing, reject everything except exclusively
properly-formatted numbers, and put the issue to bed permane
On 14/07/2020 00:46, Dale Hirt via internals wrote:
While we will no longer work on PHP builds for Windows, expect to see us remain
involved in PHP in many ways across MS as we continue supporting PHP developers
and collaborating with the community on security fixes.
I admit to a certain
On 13/07/2020 19:32, Gabriel Caruso wrote:
This warning does not make much sense as the magic method is executed
regardless of its visibility. Should it be dropped?
This seems to be the bigger issue... if something is specified as
private, nothing outside its scope has any rights to access it,
On 10/07/2020 09:54, Nikita Popov wrote:
For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace
On 07/07/2020 15:46, Larry Garfield wrote:
This has reached the 2 week mark, but there's not been much discussion. Anyone
else want to weigh in?
We wanted to add that, general sentiment seems to be moving towards
using Exceptions for communicating errors, potentially including a large
the override functions
while keeping the same base syntax.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
not sure what the alternative should be though. It seems like the
accessor syntax would be the only long-term clean way.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
might be omitted (such as if an optional package is not installed).
At which point we're left with @@@ and that's getting into silly-land.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 16/06/2020 13:14, Michał Brzuchalski wrote:
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
IMHO this RFC should not come to a vote, the current RFC process is
ill-equipped
On 22/05/2020 19:32, Rowan Tommins wrote:
* They might even prefer your RFC, which is still marked "Under
Discussion": https://wiki.php.net/rfc/php_namespace_policy
Even though the two RFCs were seperate and created without each others
knowledge, I don't know how people would feel about
an opportunity to make their case for their individual
usage of \PHP.
Should this vote fail, \PHP effectively changes from a reserved
namespace, to a dead namespace.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/05/2020 23:03, Arnold Daniels wrote:
Hi all,
I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).
I think this kind of change will have a long term positive impact, but
it will require a lot of work to update code.
IMHO we
On 15/04/2020 12:21, Mark Randall wrote:
https://wiki.php.net/rfc/php_namespace_policy
As it has come up a few times, I wanted to provide examples of where
programming languages mount their own standard libraries inside a main
namespace:
Java (java.*)
https://en.wikipedia.org/wiki
I concur with Marco's statements.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
two majors minimum, possibly
more.
Thank you for the contribution.
However, such a change would never, ever be accepted. With good reason.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/04/2020 12:21, Mark Randall wrote:
https://wiki.php.net/rfc/php_namespace_policy
Just an update in light of the two different RFCs.
Having chatted with the other RFC authors in R11, rather than racing to
see who can get their RFC to vote first, it seems like there's room for
both
On 15/04/2020 14:20, Remi Collet wrote:
Le 15/04/2020 à 13:21, Mark Randall a écrit :
Extension (pecl or other) can be include in core later
or core extension dropped and move to pecl.
Quoting the RFC:
Once approved, a namespace that is a child of \PHP will remain
exclusively
and the RFC which approved it.
In that respect it would be no different than arguing over any other
name which can already happen.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
led token, or attribute, at
which point we are back to square one, a problem which can be almost all
together avoided by adding a "feature" specific namespace under \PHP.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
internals
that the use of \PHP was permitted and encouraged.
https://wiki.php.net/rfc/php_namespace_policy
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with long lists of parameters so that
they need to be on their own lines?"
The answer to that is a pretty resounding "no".
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
If annotations RFC gets passed, there will likely be a suggested
annotation for marking things as intentional, but I would assume it
would carry no runtime effect.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is
to become a first-class feature, error handling should reflect as such
and any attempt to use objects without the appropriate handlers being
installed really should result in an error being thrown just as it would
be if an undefined method was called.
Mark Randall
--
PHP Internals - PHP Runtime
this fairly easy I'd think. We already have the
APIs and it's not much different from how the testing pipeline is set up
for github.
The docker-official PHP repos have some nice extra tools to go with them
for installing extensions mind.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing
and possible unexpected interactions.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
equest processes, as at that time there would be a
clear need for a self-contained request-specific request / response object.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n't the actual cause of failure, or worse, feeling
fed up and losing interest in future contributions because they've
failed and have no idea why.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19/03/2020 14:25, Kalle Sommer Nielsen wrote:
Why are we only attempting to harvest the negative thoughts (with the
word negative chosen carefully here as voting "No" is seemingly an
offense to some), why do we not also record why a feature was voted
in?
Well a significant part of the
the RFC
author and the wider community.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 18/03/2020 23:22, Kalle Sommer Nielsen wrote:
I am not gonna personally answer a survey everytime I vote against a
feature. This is why we have a discussion period to raise issues, of
course not everyone will raise all their concerns to each and every
RFC (me included, take the annotation
On 01/03/2020 13:29, Mark Randall wrote
I have opened voting on the get_debug_type RFC:
https://wiki.php.net/rfc/get_debug_type
Voting will run for 2 weeks and will close 2020-03-16.
Voting has now closed.
The RFC has passed with 41 in favour and 3 against.
--
Mark Randall
marand...@php.net
/php-src/pull/5265
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, but the only thing that feels worse is that we
probably couldn't pass removing null++, at least in the base version,
and that may set up null-- as the least-worst option.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/03/2020 14:08, Rowan Tommins wrote:
The problem with this kind of behaviour change is that there's no way
for PHP to know whether a particular piece of code has been changed to
expect the new behaviour or not
Lump it in with editions maybe?
--
PHP Internals - PHP Runtime Development
Greetings,
I have opened voting on the get_debug_type RFC:
https://wiki.php.net/rfc/get_debug_type
Voting will run for 2 weeks and will close 2020-03-16.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 15/02/2020 14:32, Mark Randall wrote:
Greetings,
https://wiki.php.net/rfc/get_debug_type
Just a heads up that I will be putting this to the vote tomorrow.
As this seems fairly uncontroversial, and in the absence of any
well-supported suggestions, the vote will be on adding
/
migration tool would be rather well-received, an easy mechanism to scan
a file / directory for standard extension functions with known reference
args and re-write them appropriately.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17/02/2020 08:42, Nikita Popov wrote:
Can you please add some examples for the behavior? Preferably the precise
output for all primitive types, for classes and for anonymous classes.
Added to RFC
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
a general "No".
What I can't express on this strawpoll though, is that I would
unequivocally vote against "any function or method call" in all
circumstances.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On 16/02/2020 10:16, Mike Schinkel wrote:
Why "debug" type?
I would imagine because it is only really useful in the context of
debugging. There is no reason to ever expose such information to userland.
The name is up for debate.
--
Mark Randall
marand...@php.net
--
PHP Inter
verloading operators on
objects that don't have the relevant method available should trigger an
Error.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that a supermajority may exist in
a straight up or down vote rather than a 3-way
(https://wiki.php.net/rfc/engine_warnings).
So on one hand, consistency is good.
On the other hand, being consistently bad is still being bad.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing
, thus get_debug_type will return
"int" rather than "integer" etc.
https://wiki.php.net/rfc/get_debug_type
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
zero percent
chance of it being removed at any point in the next 50 years.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or cannot exist
in a reasonably performant way? Doesn't seem so except for a readonly
property.
If not, leave it to userland.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be to simply remove support for them entirely in favour of static
methods, and at that point the door is open to make functions and
constants be global-only.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
much rather have something like:
declare(ambiguous_element_lookup=0)
declare(ambiguous_element_lookup=off)
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
now, it
would end up a compile error a few years from now.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hen PHP8 lands.
+1 from me.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
101 - 200 of 463 matches
Mail list logo
