Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Björn Larsson via internals]

Den 2023-09-11 kl. 11:28, skrev Dmitry Stogov:

Hi internals,

I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.

It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.

The old JIT implementation is going to be kept for a while.

Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079

Thanks. Dmitry.


Great work Dmitry! Looking forward to test it in next major PHP version.

Are there any performance figures available for this new JIT engine?

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations

[Björn Larsson via internals]

Den 2023-06-22 kl. 14:52, skrev Nicolas Grekas:


As previously announced on the list, we have just started the vote about
the annual PHP deprecation RFC.

Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
Link to the discussion thread: https://externals.io/message/120422

The vote is open until 2023-07-06 12:00:00 UTC.



Thanks Mate for moving all this forward.

I wish we could have voted to keep rand() and getrandmax() and just change
them to use the CSPRNG, like we do for  array_rand() & co. but I guess this
should have been proposed earlier. Might be worth a small follow up RFC to
not disrupt the current one.

Cheers,
Nicolas


Sounds like a good idea to me, keeping the functions and making them
better. Hope it will fly!

Not sure if this is a relevant comparison, but we have code that we now
need to change due to deprecation of utf8_decode and utf8_encode. It is
code that has been working flawlessly for 9 years, so it's only work and
no benefit. Given that deprecations are piling up for 8.x track I think
one should be a bit cautious when approaching the next major version.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Björn Larsson via internals]

Den 2023-04-13 kl. 10:38, skrev Mikhail Galanin via internals:

Hello good people,

Looks like another hot discussion on the list, isn't it?

Just wanted to share my notice about the initial idea.

7 years ago there were people considering NNTP as an option. Nowadays,
it's pretty clear that it isn't the way to go. It doesn't mean that
technology is bad (although, someone can share their negative
experience with that one) but instead, we hardly we can find a person
who still uses it.
If we switch to the News protocol, it is highly likely that we not
just won't engage new members but instead, we'll lose those who are
here.

Hem, I actually use the builtin NNTP client in Thunderbird connecting to 
news.php.net to follow PHP Internals. It's nice and it works :-)


Cheers //Björn L


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Future stability of PHP?

[Björn Larsson via internals]

Den 2023-04-08 kl. 20:36, skrev Stephan Soller:

Hello,

I'm sorry if this isn't the correct mailing list for that discussion but I
couldn't find a more appropriate one where people actually know how the 
wind is

blowing.

A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
deprecations and fatal errors spooked me a bit (details below if you're
interested). That got me wondering about the long-term stability of PHP 
(as in
language and API breaks) and I looked at the RFCs. I got the impression 
that
static typing has a lot of traction now and I have no idea of what the 
fallout
might be of changing a dynamically typed language into a statically 
typed one.

Also API breaks seem to become more frequent (e.g. utf8_decode). I stumbled
across the language evolution RFC proposals but it seems that approach was
abandoned.

Is there a way to tell which APIs and language features will be stable 
and which
might get changed or removed in the future? That way I could restrict 
myself to
a stable subset for long-running projects (5 to 10 years). But I realize 
that
such guarantees are difficult (or contra productive) when a language is 
in flux

and I can understand if no one wants to do something like that.

Some of my projects run for 5 to 10 years, in one case even 20 years. 
Usually
without or with very little code changes. My usual tool set for web 
projects
like that is plain PHP, HTML, CSS and JS. Everything without any 
frameworks or
unnecessary libraries and kept as simple as possible. If possible I just 
use
builtin and stable APIs and usually end up without any or with just one 
or two
dependencies (e.g. PDF generation). This isn't pretty and I end up 
trading a bit

of productivity for long-term stability. I know this is quite an unusual
approach, especially in todays web development world. But I've been 
developing
stuff for over 20 years and in most cases I have to maintain my own code 
(my
first PHP project was about 20 years ago). Without that somewhat unusual 
focus
on stability I would spend my whole time updating existing code and 
couldn't get

anything new done. And let's face it, in most situations you don't need the
perfect tool, just something that gets the job done reliably (e.g. 
sending a
query to a database and process the result). So I guess that is my 
usecase for
PHP: A stable base for long-lasting and very low maintenance server-side 
code.

The recent migration made me question that assumption, though.

Is this still something that makes sense in your opinion or would you 
recommend

to avoid using PHP for that?

A project like PHP is the result of a lot of work from many different 
people and

people, opinions and priorities change over time. The direction of PHP is
determined by those who work on it and that's a good thing. I just want 
to avoid

using the wrong tool for the job as this can quickly spiral into a lot of
unnecessary complexity and (in a somewhat best case) end in a rewrite a few
years later to stop the spiral.

I routinely rely on PHP features that are not often talked about (read 
on sexy
or fashionable) to greatly simplify my code: The alternate syntax for 
control
structures as a lightweight template system, implicit type conversions, 
streams,
SimpleXML, a DOM parser that can actually parse real-world HTML, PDOs 
and so on.
PHP has a lot of small nuggets that make it a pretty useful toolbox if 
you don't
overdo it. But did I overdo it? What I didn't realize before was the 
extend to
which I relied on the stability of APIs and core extensions listed in 
the PHP
manual. What will end up on the chopping block in the next few years? 
Can I rely
on the alternate syntax for control structures? Will streams go since 
HTTP 2 and

3 made a mess of the whole HTTP protocol? I'm note sure how to evaluate the
current situation. Hence the post.

Migration details for those who're interested:

I had PHP pegged as a dynamic language at it's core so I've used 
techniques like

duck typing and dynamic properties here and there when they were the best
compromise for simplicity and code locality.  This is nothing you would 
use in
large or inexperienced teams but for a lot of small stuff this can keep 
code
simple (it it doesn't amount to more than a few hundred lines). 
Sometimes I let
projects grow organically like that over a few years until we 
consolidate parts

that became to complex once the usecases became clear. Unfortunately this
backfired on me during a recent migration. The amount of deprications 
and out

right fatal errors caught me off guard. Dynamically extending objects got
deprecated in PHP 8 except for stdClass and the AllowDynamicProperties 
attribute

which sounds reasonable. Unfortunately I ran right into the corner case of
attaching dynamic properties to a Generator which caused a fatal error. 
The rest
of the code then used duck typing to work with those properties 
(basically just
isset() checks that use the additional information if 

[PHP-DEV] Re: [RFC] PHP Technical Committee

[Björn Larsson via internals]

Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka:

Hello,

Here is a proposal for an introduction of the PHP Technical Committee:

https://wiki.php.net/rfc/php_technical_committee

The main purpose of this RFC is to have better decision process when
technical conflicts between developer arise.

This was created in collaboration with other people involved in PHP core
development and the PHP Foundation. Larry has done a lot of work in
rewording the text and he is also a co-author of this RFC.

Feel free to comment here or if you have just some wording suggestions
there is also a PR in my util repository for easier collaboration on the
text: https://github.com/bukka/php-util/pull/1 . So feel free to comment /
send suggestion there as well.

Regards

Jakub


I think this is a very good initiative, so good luck with it!

Question:
- Is this something that could be used to point out general areas for 
improvement of PHP, e.g. like a roadmap/wishlist for 9.0?


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

[Björn Larsson via internals]

Den 2023-01-18 kl. 13:22, skrev G. P. B.:

On Tue, 17 Jan 2023 at 18:28, Mark Baker  wrote:


On 17/01/2023 17:28, Craig Francis wrote:

I've seen this used a few times, e.g. starting with a numerical value

(Passport number, NHS number, Social Security Number, Date of Birth
20230117), and the developer simply appends an incrementing letter on the
end to get a unique reference; e.g. a person having multiple assessments...
especially if it's more than 26 (A-Z), and you need to move to multiple
letters, which `chr(90 + 1)` cannot help you with.

Being able to increment alpha strings is incredibly useful when working
with Excel spreadsheets (as I do on a daily basis), because the column
Ids match this pattern; and I would hate to see this deprecated. Having
to replicate that logic for traversing column Ids in userland code would
be inconvenient (to say the least), would affect many of the users of my
libraries, and would have a performance impact on my libraries. If
anything, I'd rather like to see the decrement operator work with alpha
strings as well for more consistency.

I don't have the karma for a vote; but if I did then it would be a "No"
for this alone, because I can see the problems that it will cause me and
the users of my libraries.



That said, I appreciate that incrementing some strings can be a bit

unusual (e.g. "A9" to "B0", vs "A 9" to "A 0").

Agreed. While incrementing works in a very logical manner with mixed
alphanumeric strings, it's not well documented behaviour, and most
developers take a long time before they understand what it's actually
doing. While there might be use cases for incrementing alphanumerics, I
suspect that it would be better implemented in the business logic of an
application, because the component parts of that string are likely to
have business meaning; and also to provide better code readability.



I appreciate being shown concrete cases about the useful ness of this
operation.
The reason I didn't go with adding support for decrementing alphanumeric
strings is that it was unanimously rejected.
However, if Rowan's suggestion of adding
string_increment()/string_decrement() with more rigorous behaviour (that we
can flesh out together) would be part of this proposal, would you be more
inclined to accept deprecating ++ from performing this feature?

I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -=
1; is something to strive for *because* it allows us to remove one
dedicated type juggling context people need to be aware of and simplifies
the overall semantics of the language.
Keeping support for string increments means that one cannot interchange $v++
and $v += 1 and that one needs to be aware about using it when a value
might hold a string.
As such, if it needs to remain its own type juggling context, the question
is why not make it stricter by having it warn and then throw a TypeError on
bool, reopening the can of worms that is the null handling between both
operators and what to do with the empty string case.
These questions are already answered by making those operators behave just
like addition/subtraction.

My order of preference for the semantics are as follows:
1. The behaviour described in the RFC (with or without function for string
in/decrement)
2. (with a massive gap, but I could live with it) adding support for string
decrements and tiding up the behaviour of the alphanumeric string to make
it stricter and less error-prone.
3. The current asymmetry (again with a massive gap between this and option
2)

But because option 2 seems out of the question due to the unanimous
rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only
viable options to me seem like 1 and 3.
As I hate option 3 I am pushing for option 1 as I think it has various
benefits.


Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago,
could it be an option to bring it up again in conjunctione with your RFC?

Maybe the added value of your RFC could swing the opinion. I mean there has
been RFC's that required multiple tries to fly.

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

[Björn Larsson via internals]

Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux:

On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi  wrote:


Hello internals,

I've started the vote for the Constants in Traits RFC:
https://wiki.php.net/rfc/constants_in_traits

The vote will end on 19. July 2022.

Thanks!

--
Shinji Igarashi



I don't have a vote, but I wanted to address this concern about the
"usefulness" of traits, since the *voting* stage is rather the wrong place
to bring up the idea that the existence of the feature itself is a
negative.

In my view, the "correct" way to use traits is for them to be entirely
self-contained. That is, if you can put the trait in *any* class, and have
that trait work as intended *even if* it makes no semantic sense to do so,
then it's a good trait. This is currently somewhat difficult to do in
certain situations. Some of the things the trait may need must live outside
the trait, such as constants. This fact promotes further problematic usage
of the feature.

Requiring something like class constants to be external to the trait
*forces* the kind of trait designs that they have complained about. Voting
"no" because you want to see the feature removed instead is
counter-productive to the process of improving the language itself if the
RFC in question helps correct an oversight of the original feature design
as stated by the original implementer of this feature and helps to promote
more non-problematic usage of the feature.

I don't know how else to view that position except for wanting to keep
design flaws in a feature so that you have additional arguments in the
future to remove it.

Jordan


I think it's quite unlikely to deprecate such a rather big feature and
from that perspective I think one should do it as good as possible.

Even if one thinks that this is a bad feature not to be expanded, why
not try to make it work better? So, I hope this RFC passes!

Regards //Björn L

--
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

[Björn Larsson via internals]

Den 2022-06-29 kl. 19:30, skrev Larry Garfield:

On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:

Last year, Nuno Maduro and I put together an RFC for combining the
multi-line capabilities of long-closures with the auto-capture
compactness of short-closures.  That RFC didn't fully go to completion
due to concerns over the performance impact, which Nuno and I didn't
have bandwidth to resolve.

Arnaud Le Blanc has now picked up the flag with an improved
implementation that includes benchmarks showing an effectively net-zero
performance impact, aka, good news as it avoids over-capturing.

The RFC has therefore been overhauled accordingly and is now ready for
consideration.

https://wiki.php.net/rfc/auto-capture-closure


The conversation has died down, so we'll be opening the vote for this tomorrow.

Two changes of note since the discussion started:

* The option to mix explicit capture and implicit capture has been removed as 
too confusing/unpredictable.  Either trust the engine to capture the right 
things (the new syntax proposed here) or explicitly list everything (the 
existing syntax we've had since 5.3.)
* We added a section discussing the `use(*)` syntax alternative, and why it 
wasn't, er, used.  (Pun only sort of intended.)

--Larry Garfield


Hi,

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!

Regards //Björn Larsson

--
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

[Björn Larsson via internals]

Den 2022-06-13 kl. 14:57, skrev Arnaud Le Blanc:

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
```
I like this idea very much. In the RFC two variables are captured

explicitly and one implicitly.
$c = 1;
fn () use ($a, &$b) { return $a + $b + $c; }

I don't see the UC / value for not specifying $c while specifying
$a. Think it's much clearer when capturing variables to implicitly
capture everything or list the ones that should be captured. One
only need to think about which variables are listed, not the ones
that might be implicitly captured.

Of course capturing by reference will always be required to list
and if combined with capturing variables by value, they also needs
to be listed.

The there is this other proposal to enhance traditional anonymous
functions by allowing the syntax use(*), meaning capture everything.
Even if it's outside the scope of this RFC it could be mentioned in
"What about Anonymous Functions?" or "Future scope".

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Björn Larsson via internals]

Den 2022-05-08 kl. 08:52, skrev Aleksander Machniak:

On 07.05.2022 23:11, Jordan LeDoux wrote:
What exactly would be the purpose of `?int` if this RFC was passed? To 
pass

the value as null instead of 0? That's it?


Yes. No change here.


What about `int|float`? Which one would it be coerced to?


What happens if you pass FALSE to such an argument? int(0). The same 
would happen with NULL.



This pretty radically changes how typing itself
would work in existing user programs. What I'm saying is that for such a
radical BC break you need to provide some compelling justification.


If coercion is possible it should be done as it is done for 
bool/int/float/string. Inside the function you can still trust the 
variable type is as expected. The only difference is that it will not 
throw an error on NULL. Right now you can still use your function 
"incorrectly" and not get an error, e.g. if you pass FALSE to it (I 
understand NULL might be more common). And, if you use strict_types=1 
nothing changes for you.


I don't see this as a radical change. Definitely not more radical than 
making the code to throw errors where they were not thrown before (no 
matter how long the deprecation period was). So, imo the BC-break 
argument is not that strong in this case.


The consistency argument is also not that strong (but here probably more 
in favor of the change) because as it was mentioned already current 
behavior is consistent with some things and inconsistent with others.


The essential question is whether we want more of "weak-typing coercion" 
or not. More would mean that there's no breakage for existing code in 
PHP9 (essentially only 8.1 would be "broken" (because of the deprecation 
notice) so people could just skip it). No need for ugly code like "$var 
?? ''" everywhere is also a win.



It's not only ugly code ;) To make your program/application/library 8.1
compatible using that codepattern requires en effort, but brings close
to zero improvement, except being 8.1 compatible. So the net effect is
negative.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: NULL Coercion Consistency

[Björn Larsson via internals]

Den 2022-04-08 kl. 19:34, skrev Craig Francis:

Hi,

I've written a new draft RFC to address the NULL coercion problems:

https://wiki.php.net/rfc/null_coercion_consistency

This is due to the result of the Allow NULL quiz:

https://quiz.craigfrancis.co.uk/

14 votes for Fatal Type Errors irrespective of `strict_types=1`;
13 votes for NULL coercion when not using `strict_types=1`;
8 votes to update some parameters to allow NULL;

I appreciate some want to force strict type checking on everyone, but I
want to make sure we have this properly documented, with names, and
explanations.

Breaking changes should be justified - if they aren't, they only
make upgrading difficult and frustrating (bad for security).

Craig


Hi,

Have been busy for a while and haven't followed all the details around
this RFC, but now back on track.

One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the
null coalescing operator like rtrim($string ?? '',...).

If one then has a legacy codebase that works flawlessly I would say that
this path is the preferred one since it requires a minimum of work. To
dig into your code base and address why the parameter ends up like null
is probably more cumbersome. OTOH, one doesn't reap the benefits of the
"Deprecate passing null to non-nullable arguments of internal functions"
RFC since it requires to much work.

One could argue that the "Deprecating passing null" RFC is nice, but has
a flaw when applied for existing code. Applying the null coalescing code
pattern is an easy way to make your code 8.1 compatible, but not sure if
it adds value to the application itself.

Now if this RFC is the best way to improve things if one think this is
something of an issue with the original RFC worth addressing I don't
know. But at least worth having a discussion about! The purist within
me sighs a little when applying the code pattern above...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add true as type

[Björn Larsson via internals]

Den 2022-04-08 kl. 18:47, skrev G. P. B.:

Hello internals,

I would like to open the discussion on the RFC to add true as a type.
https://wiki.php.net/rfc/true-type

Now that null and false can be used as standalone types, I think it makes a
lot of sense to add true as a value type for the sake of completeness with
false.

It also has many use cases within internals and userland to declare proper
type signatures to functions and methods.

Best regards,

George P. Banyard


Finally, I have been waiting for this :) Two comments:
- Would be nice to have an example / UC that shows the value of true as 
a type in the RFC.
- Should one have a link to the earlier discussion about this type, 
either in the RFC or in the announcement on the internals list?


Regards //Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Undefined variables and the array append operator

[Björn Larsson via internals]

Den 2022-03-29 kl. 21:44, skrev Rowan Tommins:

Hi all,

If $foo is not defined, statements such as $foo += 1 and $foo .= 'blah' 
raise "undefined variable" Warnings in PHP 8, and will throw Errors in 
PHP 9. However, the very similar looking $foo[] = 1 succeeds silently.


This seems odd to me, as "append to string" and "append to array" seem 
like very similar operations, with most of the same use cases and 
possible bugs.



 From an *implementation* point of view, this is presumably because they 
are defined as different Op Codes - ASSIGN_OP for .= and ASSIGN_DIM for 
[]=, I believe. But that doesn't explain *why* ASSIGN_DIM behaves this way.


A *historical* explanation might relate to Perl's "autovivification" 
feature. However, PHP does *not* implement the same rules as Perl: for 
instance, Perl will create array dimensions just by reading them, which 
PHP does not; and Perl has a completely different type system, with 
cases like "a scalar becomes a reference to a hash unless already a 
reference to a list". Note also that I'm *not* talking about 
multi-dimensional arrays with missing keys here, only undefined local 
variables, as were the subject of the recent RFC.


The *observable behaviour* for most operators in PHP is the same:

1) if the variable is undefined, consider the value to be null
2) coerce the value to the appropriate type; if the value is null, this 
gives the relevant "empty" value, such as '', 0, or []

3) apply the operator

There isn't anything particularly special with $foo[] = 'bar' in this 
case, except that it's the only operator that doesn't raise a Warning 
(and planned Error) at step 1. The same goes for all the other uses of 
the [] syntax I can think of, like $foo['key'] = 'bar', or $ref =& $foo[].



For example, consider the following simple validation code 
[https://3v4l.org/pP5CU]:


$requiredFields = ['name', 'age', 'hair_colour'];

// Note: $errorString is not initialised
foreach ( $requiredFields as $field ) {
     if ( ! isset($_POST[$field]) ) {
     $errorString .= "Missing required field '$field'. ";
     }
}
echo $errorString;

This gives an "Undefined variable" Notice / Warning / Error, depending 
on the version. That's reasonable, as failing to initialise $errorString 
might cause problems if this code is integrated into a loop or larger 
function later.


However, switch the code from building up a string to building up an 
array, and the result is identical, but the Notice / Warning / Error 
goes away [https://3v4l.org/ojZ1O]:


// Note: $errorArray is not initialised
foreach ( $requiredFields as $field ) {
     if ( ! isset($_POST[$field]) ) {
     $errorArray[] = "Missing required field '$field'. ";
     }
}
echo implode('', $errorArray);


Can anyone give a compelling reason why we should keep this 
inconsistency, or should I raise an RFC to bring it in line with other 
undefined variable accesses?



I think it deserves an RFC. Then we also capture your excellent 
explanation above!


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Björn Larsson via internals]

Den 2022-03-24 kl. 19:48, skrev Rowan Tommins:

On 24/03/2022 15:51, Björn Larsson wrote:

Well, the usecase I can provide is that we have a site with content
in ISO9959-1 (Latin 1).



Thanks for the data point. Out of curiosity, what language is the site 
in, and where are you based?



It's in swedish and I'm located in Sweden.

One of the things missing from Latin-1 is the Euro symbol (because it 
wasn't invented yet), so I'm guessing your site doesn't need that?


No, we are not using that one. In one specific case for payment we just 
write euro ;-)



I also find the usage of both functions in one of our most important
Open Source libraries. How important they are there I don't know. 



Can you point me to the library in question? I'd be interested to see 
how they're using it.


Yes, it's the Revive Ad server. At the moment we are on v4, going for 
v5.4 as soon it's released.


Regards //Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Björn Larsson via internals]

Den 2022-03-23 kl. 14:46, skrev Rowan Tommins:

On 20/02/2022 18:55, Rowan Tommins wrote:


I would like to open discussion on an RFC to deprecate and later 
remove the functions utf8_encode() and utf8_decode()


https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode



Final chance for feedback on this RFC, as revised, before I put it to a 
vote.


There's been very little reaction on this thread, which I'm hoping means 
everyone's either planning to vote "Yes" or just doesn't care...


Regards,


Well, the usecase I can provide is that we have a site with content
in ISO9959-1 (Latin 1).

Now the utf8_decode are used in the backend when the webapps and site 
are communicating with DB, e.g. in Ajax calls. The webapps are

built in Javascript.

Our feedback would be that the usage of this function have had zero
issues or bugs for more then five years that e.g. the apps have been
in production. So in this specific use case there is no benefit at the
moment with this removal. OTOH, the usage of this function is mostly
wrapped so it's not a big job changing it and it's good that the RFC
points out alternatives, where we would go for mbstring.

I also find the usage of both functions in one of our most important
Open Source libraries. How important they are there I don't know.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Community to support Ukraine and help to stopRussian agression

[Björn Larsson via internals]

Den 2022-03-05 kl. 23:26, skrev Kris Craig:

On Sat, Mar 5, 2022 at 7:05 AM  Good Guy   wrote:


On 05/03/2022 11:45, Sergey Panteleev wrote:


Several members have asked not to have a debate on this mailing list,
let's respect their opinions too.





It's not debating. The original post was simply asking to show true
colors of Ukraine's flag in these posts but HTML is not allowed here. I
have created a simple HTML code that show something like this:

Arrest Dictator Putin 


--

With over 1.7 billion devices now running Windows 10/11, customer
satisfaction is higher than any previous version of windows.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Ffs this is exactly what I'm talking about!  Are we talking about putting

out a statement of solidarity with the victims of war or are we talking
about putting out a political statement demanding the arrest of a world
leader?  *THE TWO ARE NOT ONE AND THE SAME!! *

So before we continue any further, we need to figure out EXACTLY what's
being proposed here because everybody seems to have a wildly different
interpretation of that.  Specifically, I would direct this question to
Pierre and Viktor:  Do you believe that "Arrest Dictator Putin" is
appropriate for the PHP homepage?  Is that what you meant when you said you
support a statement of solidarity?  I'm asking because it seems like there
are two very distinct camps among those who want to put out a statement:
One camp wants to express solidarity while the other seems more concerned
with personally condemning Vladimir Putin and demanding his arrest.

I'd feel a lot better about this if people would clarify which of these
camps they fall into.  It would be one thing if we had previously put up
something like "Arrest Dictator Bush" back in the day, but we didn't.  And
I'm not comfortable with the implied statement we'd be making that one
illegal invasion that displaces and murders innocent civilians is ok but
the other is not.

Could somebody please suggest a less politically divisive banner?  It
should focus on standing with the victims of war, not demanding arrests and
prosecutions.  That's not what the PHP homepage is for.


Well, I think that whatever the PHP community decide one should take
into account how it affects active PHP contributors that lives in Russia.

There is a recent Russian 'fake news' law which gives 15 years in
prison. So maybe it's a longshot to imagine that Russian authorities
would crack down on a PHP community member in Russia for something
stated in that programming community. Anyway, it's an angle I wanted
to bring up.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allowing NULL for some internal functions

[Björn Larsson via internals]

Den 2022-01-02 kl. 00:17, skrev Craig Francis:

On Thu, 2 Dec 2021 at 15:19, Sara Golemon  wrote:


On Thu, Dec 2, 2021 at 8:48 AM Craig Francis 
wrote:


Is there any value in me proposing an RFC to update *some* internal
functions so they can accept NULL?



I'm not hard against this idea.  The interpretation of null in these
contexts as being equivalent to empty string isn't unreasonable.  I guess
the only objection I could have would be an academic one and I can't really
defend that.  So yeah, sure... why not?




Thanks Sara,

I've spent a few days coming up with a short(ish) list of parameters that
are likely to receive `NULL`.

The focus is on making it easier for developers to upgrade to newer
versions of PHP. I'm thinking of the typical developer, probably using
WordPress, isn't using Psalm (at levels 1 to 3, with no baseline), and
isn't using `strict_types`; where they don't really have the time to add
strval() to everything that could be NULL.

Draft RFC:
https://wiki.php.net/rfc/allow_null

And the list, where I'm proposing we only relax this requirement for the
*bold* parameters:
https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-change.md

I'll give it a few weeks to see if there are any parameter suggestions
(welcome via email, pull request, carrier pigeon, etc), then I'll start
looking for the best way to implement this.

Craig


PS; starting new thread, as I have gone a bit off topic, original one at:
https://externals.io/message/116519#116556


Hi,

Thanks for this RFC! I think it could interesting to see how libraries
that needs to adapt to this are doing it IRL.

One example I have seen how to fix this for e.g. substr is to replace:
$result = substr($string, 0, $length)
with:
$result = substr($string ?? '', 0, $lenght)

So the null coalescing operator comes in quite handy ;-) Now if this is
a good way to solve it is another matter. But if you are a maintainer of
a library that works fine and wants to support PHP 8.1 this will solve
the upgrade in a smooth way.

Would be interesting to see how common this approach is for solving
PHP 8.1 upgrades for non-nullable arguments with internal functions?

I mean, it shows the value with the RFC from a slightly another angle.

Regards //Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Björn Larsson via internals]

Den 2021-11-15 kl. 10:52, skrev Derick Rethans:

Dear Internals,

On Wed, 10 Nov 2021, Nikita Popov wrote:


On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov  wrote:


This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little impact on modern code (e.g. in Symfony I could fix the vast
majority of deprecation warnings with a three-line diff), but may
have a big impact on legacy code that doesn't declare properties at
all.



I plan to open voting on this RFC soon. Most of the feedback was
positive, apart from the initial choice of opt-int mechanism, and that
part should be addressed by the switch to the
#[AllowDynamicProperties] attribute.


The voting is now open, but I think one thing was not taken into account
here, the many small changes that push work to maintainers of Open
Source library and CI related tools.

In the last few years, the release cadence of PHP has increased, which
is great for new features. It however has not been helpful to introduce
many small deprecations and BC breaks in every single release.

This invariably is making maintainers of Open Source anxious, and
frustrated as so much work is need to keep things up to date. I know
they are *deprecations*, and applications can turn these off, but that's
not the case for maintainers of libraries.

Before we introduce many more of this into PHP 8.2, I think it would be
wise to figure out a way how to:

- improve the langauge with new features
- keep maintenance cost for open source library and CI tools much lower
- come up with a set of guidelines for when it is necessary to introduce
   BC breaks and deprecations.

I am all for improving the language and making it more feature rich, but
we have not spend enough time considering the impacts to the full
ecosystem.

I have therefore voted "no" on this RFC, and I hope you will too.

cheers,
Derick


Hi,

Maybe the RM's should have a mandate to keep track on deprecations for
a specific release and be able to say: "Sorry the shop are closed for
further deprecations in this release".

What do you think?

One could count the deprecations in the 8.x track and have a straw poll
on it and/or ask what key deprecations do we see further for the 8.x?

Is even the "Dynamic properties" one, one of the last ones?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Björn Larsson via internals]

Den 2021-11-02 kl. 15:19, skrev Nikita Popov:

Hi internals,

The migration from bugs.php.net to GitHub issues has already been discussed
in https://externals.io/message/114300 and has already happened for
documentation issues.

I'd like to formally propose to use GitHub for PHP implementation issues as
well: https://wiki.php.net/rfc/github_issues

Regards,
Nikita


Hi,

The current proposal is to move all new issues from bugs.php.net to
Github except security ones.

I think it's important to think a bit on what that means for reporting
security issues in the future. I mean, if we leave bugs.php.net to rot 
in the corner, what are the consequences for reporting security issues?


I think that aspect needs to be a bit further analysed like:
- Will this move have a negative impact on reporting security issues
  on bugs.php.net?
  # Both from a technical and people perspective.
- Can one assume that by bugs.php.net having probably even less
  attention, that reporting security issues will work as is?
- Is there an alternative for also handling security issues?

Think it would be good if the RFC could analyse that a little, besides 
saying business as usual for security issues.


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Björn Larsson via internals]

Den 2021-09-06 kl. 18:22, skrev Christian Schneider:

Am 06.09.2021 um 18:08 schrieb Benjamin Morel :

Yes, please! A future where dynamic properties are only allowed on
DynamicObject is bright.


I have nothing against a DynamicObject alias for people who like to be more 
explicit in their code...



Totally agree here!


I would even deprecate the stdClass alias straight away, so that the whole
thing can be gone in PHP 9.


... but I'd prefer retaining a backward compatible version for library code, at 
least for a while and preferably without warnings :-)

- Chris


Couldn't agree more on the statement "without warnings"!

I mean if one have code that is in production, is running perfect and
one wants to upgrade to the newest and fanciest PHP version and the
logs are flooded with warnings for a deprecation with zero impact on
functionality. What do one do? Maybe just turn of the warnings for
that code section / library ;-)

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Alias stdClass to DynamicObject?

[Björn Larsson via internals]

Den 2021-09-06 kl. 17:28, skrev Nikita Popov:

Hi internals,

In the thread for deprecation of dynamic properties, Rowan suggested that
we alias "stdClass" to "DynamicObject" in
https://externals.io/message/115800#115802. I wanted to split this
discussion off into a separate thread, as this can be decided independently.

The rationale for this is that "stdClass" is something of a misnomer: The
name makes it sound like this is a common base class, as used in a number
of other languages. However, PHP does not have a common base class. The
only way in which "stdClass" is "standard" is that it is the return type of
casting an array to (object).

The actual role of stdClass is to serve as a container for dynamic
properties, thus the suggested DynamicObject name.

What do people think about adding such an alias? Is this worthwhile?

Regards,
Nikita



Well, we have legacy code where stdClass is quite prevalent and the code
works just fine!

In case of deprecation of stdClass I would like to point out that the
benefit of replacing "new stdClass" with "new DynamicObject" in our
existing code is absolutely zero. However, using DynamicObject in new
code has a benefit since the intent is clearer.

I think one also should take into account how much is stdClass described
in documentation and books. Reason is that deprecation is not just about
how it affects code. I'm a bit of a book worm so I'll check up on how
the usage of stdClass is described in some PHP books.

If deprecation of stdClass is on the table I think it should target the
last 8.x or 9.0 zero release.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: 8.1 / Exception / Property Type / Backwardscompatbility

[Björn Larsson via internals]

Den 2021-08-26 kl. 20:34, skrev Ben Ramsey:

Nikita Popov wrote on 8/26/21 09:57:

Right. I at least do not plan to address this issue. If you take a
protected property and publicly re-export it, then any compatibility issues
are on you.


This does not appear to affect only cases where one is re-exporting a
protected property as public.

Exception protected properties without type hints:

* PHP <= 8.0 - https://3v4l.org/GWmrk
* PHP 8.1 - https://3v4l.org/GWmrk/rfc


Exception protected properties with type hints:

* PHP <= 8.0 - https://3v4l.org/UX1Pa
* PHP 8.1 - https://3v4l.org/UX1Pa/rfc

Cheers,
Ben


So it looks like we have a bug here since the same code behaves
differently between 8.0 and 8.1.

I don't think it's obvoius that by adding a type hint we get
different behaviour for the "same" code in 8.0 vs 8.1.

The reason I brought this up is that in an Open source library
it's discussed how to solve this. Loading different versions of
the libray feels clunky.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: 8.1 / Exception / Property Type / Backwards compatbility

[Björn Larsson via internals]

Den 2021-08-10 kl. 11:55, skrev Philip Hofstetter:

Hello

The following valid <= PHP 8.0 code that intends to make the $line property
public  is a fatal error in 8.1

class FooException extends Exception {
 public $line;
}

However, the fixed code for 8.1:

class FooException extends Exception {
 public int $line;
}

Is a fatal error in <= 8.0

Is there a way to create a class that makes the $line property public
that’s compatible with all versions of PHP without requiring conditional
declaration of the class?

For method return types, we have #[ReturnTypeWillChange], but for property
types 路‍♀️

Philip


Hi,

Has this been adressed / solved in some way and does it needs
to be fixed?

I mean we are approaching RC1.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Björn Larsson via internals]

Den 2021-08-25 kl. 12:02, skrev Nikita Popov:

Hi internals,

I'd like to propose the deprecation of "dynamic properties", that is
properties that have not been declared in the class (stdClass and
__get/__set excluded, of course):

https://wiki.php.net/rfc/deprecate_dynamic_properties

This has been discussed in various forms in the past, e.g. in
https://wiki.php.net/rfc/locked-classes as a class modifier and
https://wiki.php.net/rfc/namespace_scoped_declares /
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
as a declare directive.

This RFC takes the more direct route of deprecating this functionality
entirely. I expect that this will have relatively little impact on modern
code (e.g. in Symfony I could fix the vast majority of deprecation warnings
with a three-line diff), but may have a big impact on legacy code that
doesn't declare properties at all.

Regards,
Nikita


I'm in favour of the proposal as long as the stdClass is leaved as is!
For declared classes I think it's a good idea.

We have legacy code that is littered with dynamic properties using
stdClass. It runs today on PHP 7.4.22 and we plan to migrate to PHP 8
as soon as some Open source libraries works under PHP 8.

Being forced to rewrite this if this proposal changes to also disallow
stdClass dynamic properties would have zero benefits for the app itself
and only incur a cost.

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Björn Larsson via internals]

Den 2021-06-28 kl. 16:52, skrev Nikita Popov:
On Mon, Jun 21, 2021 at 4:26 PM Björn Larsson 
mailto:bjorn.x.lars...@telia.com>> wrote:


Would you look on this feature in a different light if the above
concerns about strict types and nullsafe calls could be clarified /
solved? Or is it about the implementation with it's complexity and
tricky edge cases?


These were just some notes on implementation details, they don't 
really impact my overall opinion of the RFC. I should also say that 
I'm not strongly opposed here, I'm just not convinced this is 
worthwhile :) The complexity of the feature would be rather easy to 
overlook if I felt the functionality was important.


I myself think one should take into account that this is a feature
that would make PHP stand out even more. Not being a follower of
other languages here :-)


Heh, it's the other way around for me: This just makes me more 
apprehensive. Is there some special property of PHP that makes this 
feature more relevant to us than other languages? All other mainstream 
languages do well without this feature, so why do we need it?


Regards,
Nikita


Well, I think the weak spot in the RFC is the motivation why do we need it.

OTOH, Larry posted the "The case for partials and pipes in PHP":
- 
https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-php


Two things caught my eye there, namely the Health check & HTTP pipeline
and also the Scalar thing. Think it would have been good if these had been
part of the discussion phase and also highlighted a little in the RFC 
itself.


So do you think these are good motivations on why we need it?

Regards //Björn L

Re: [PHP-DEV] [RFC] New in initializers

[Björn Larsson via internals]

Den 2021-06-17 kl. 12:08, skrev Nikita Popov:

On Thu, Jun 17, 2021 at 11:53 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:


Le Wed, 16 Jun 2021 10:16:37 +0200,
Nikita Popov  a écrit :


1. Eagerly evaluate initializers on declaration. This is what I tried in

an

earlier revision of the RFC, and I don't think that approach works. It
breaks existing code and has various other unpleasant complications.
2. Precisely specify the current behavior. I don't want to do this

either,

because the exact places where evaluation happens are something of an
implementation detail. If in the future we find it convenient to separate
evaluation of non-static properties on object instantiation from

evaluation

of static properties and class constants (which are not strictly needed

at

that point), I'd like to retain the liberty to make such a change.
3. Do not specify an evaluation order, beyond that evaluation happens at
certain uses of the class. Evaluation order may change across PHP

versions.

If your code relies on any particular order, your code is broken.


If option 3 is considered, it means the evaluation order may change, if we
can
change the evaluation order, why not go for option 1? I do not understand
which
existing code can break with option 1 and be fine with option 3, it means
this
code relies on undefined behaviors, no?



See the example in https://externals.io/message/113347#113642. I'm not sure
how common this is, but I expect this kind of pattern does get used in PHP
code not using autoloading and declaring multiple classes perf file.

What this relies on is not so much that evaluation happens at a specific
place, but that it doesn't happen during initial class declaration, which
is exactly the assumption that would be broken by option 1.

Regards,
Nikita


Is this a case where we go for the current scope in 8.1 and then extends
it in 8.2 with static property and class constant initializers or do we
include it already in 8.1?

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] Partial Function Application

[Björn Larsson via internals]

Hi and thanks for the clarification!

So if I get it right, by not addressing null safe calls and strict types 
now we can address it later when we know a little bit more, which btw is 
not the first time it's done. And the feature proposed requires a non 
trivial implementation.


I think it should be noted that this is a feature where PHP is in the 
forefront of language development, not a follower.


Of course it requires some afterthought, which I think the RFC fulfils 
giving a broad explanation on  why it is like it is. Maybe a bit weak on 
the use cases, besides Pipe operator that would benefit from this feature.


So I hope it passes, +1 from me (not having a vote though).

Regards //Björn L

Den 2021-06-21 kl. 18:27, skrev Joe Watkins:


I'd like to note a couple of things ...

The behaviour of nullsafe and strict types being unspecified in the 
RFC would allow us to solve those problems later.


The behaviour of strict types right now is objectively wrong, the 
partial takes strictness from the application site, so as Nikita 
already knew when he asked the question; calls from a non-strict file 
will not behave as you expect.


With regard to the complexity in the implementation: I think it's 
important to understand that the complexity of the implementation is a 
product of the semantics we landed on during discussion.


The first implementation where we only had ? was technically simpler, 
but not intuitive from a user perspective.


Now we have semantics that are easy to understand, that you can 
communicate in a few lines. But the implementation is necessarily 
complicated as a result of those semantics.


We also have to remember that this is actually some kind of middle 
ground, it's not the most complicated version of partial application 
we could have - because that most complicated version would also 
include support for re-ordering parameters (named placeholders), and 
nor is it the simplest which offloaded a lot of (cognitive) overhead 
onto the programmer.


The question is not can we simplify the implementation, the question 
is rather, is the necessary complexity of an implementation with the 
kind of semantics that are desirable justified.


Cheers
Joe




On Mon, 21 Jun 2021 at 16:26, Björn Larsson via internals 
mailto:internals@lists.php.net>> wrote:


Den 2021-06-18 kl. 16:08, skrev Nikita Popov:
> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield
mailto:la...@garfieldtech.com>>
> wrote:
>
>> Hi folks.  The vote for the Partial Function Application RFC is
now open,
>> and will run until 30 June.
>>
>> https://wiki.php.net/rfc/partial_function_application
<https://wiki.php.net/rfc/partial_function_application>
>>
>> Of particular note, a few people had asked about using ...?
instead of ...
>> for the variadic placeholder.  In the end we decided not to
explore that,
>> as Nikita explained off-list it was actually more confusing,
not less, as
>> it would suggest "placeholder for a variadic" rather than "a
placeholder
>> that is variadic."  Otherwise, it's just more typing.  The
syntax choices
>> section of the RFC has been updated accordingly.
>>
>
> A couple of notes on the content (or non-content) of the RFC:
>
> * The behavior of nullsafe calls with PFA has been brought up in the
> discussion, but is not mentioned in the RFC. For reference,
$foo?->bar(?)
> is the same as $foo !== null ? $foo->bar(?) : null. I don't
think the
> behavior is particularly unreasonable, but I also think it's not
> particularly useful and may be surprising (in that there is a
plausible
> alternative behavior). I think you may have been better off
forbidding that
> case.
>
> * The behavior of parameter names / reflection with regard to
variadic
> parameters is very odd. For function test(...$args) and test(?,
?, ?) you
> get back a function that nominally has three parameters with the
name
> $args. Parameter names in PHP are generally required to be
unique, and of
> course this also has implications for named arguments, for
example this
> works, while it probably shouldn't:
> https://3v4l.org/cQITD/rfc#focus=rfc.partials
<https://3v4l.org/cQITD/rfc#focus=rfc.partials> To be honest, I'm
not sure
> what the right way to handle this is, but I don't think this is
it. A
> possibility would be to bring back the concept of name-less
parameters we
> had prior to PHP 8 (for internal functions only), or possibly to
make the
> signature less precise by simply retaining an ...$args
parameter, and just
> making the enforcement of "at least three parameters" an
i

Re: [PHP-DEV] [Vote] Partial Function Application

[Björn Larsson via internals]

Den 2021-06-18 kl. 16:08, skrev Nikita Popov:

On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield 
wrote:


Hi folks.  The vote for the Partial Function Application RFC is now open,
and will run until 30 June.

https://wiki.php.net/rfc/partial_function_application

Of particular note, a few people had asked about using ...? instead of ...
for the variadic placeholder.  In the end we decided not to explore that,
as Nikita explained off-list it was actually more confusing, not less, as
it would suggest "placeholder for a variadic" rather than "a placeholder
that is variadic."  Otherwise, it's just more typing.  The syntax choices
section of the RFC has been updated accordingly.



A couple of notes on the content (or non-content) of the RFC:

* The behavior of nullsafe calls with PFA has been brought up in the
discussion, but is not mentioned in the RFC. For reference, $foo?->bar(?)
is the same as $foo !== null ? $foo->bar(?) : null. I don't think the
behavior is particularly unreasonable, but I also think it's not
particularly useful and may be surprising (in that there is a plausible
alternative behavior). I think you may have been better off forbidding that
case.

* The behavior of parameter names / reflection with regard to variadic
parameters is very odd. For function test(...$args) and test(?, ?, ?) you
get back a function that nominally has three parameters with the name
$args. Parameter names in PHP are generally required to be unique, and of
course this also has implications for named arguments, for example this
works, while it probably shouldn't:
https://3v4l.org/cQITD/rfc#focus=rfc.partials To be honest, I'm not sure
what the right way to handle this is, but I don't think this is it. A
possibility would be to bring back the concept of name-less parameters we
had prior to PHP 8 (for internal functions only), or possibly to make the
signature less precise by simply retaining an ...$args parameter, and just
making the enforcement of "at least three parameters" an implementation
detail. The latter seems like the best option.

* The RFC doesn't specify how PFA interacts with strict types. If I create
a partially-applied function in strict_types=1 file and call it in a
strict_types=0 file, what happens? Will it use strict_types=0 semantics,
including for arguments that were bound in the strict_types=1 file?

* It's worth noting that the "new Foo(?)" syntax will create and destroy a
Foo object as part of creating the partial (not just a call to the
partial). I've mostly convinced myself that this is *probably* harmless. It
would have interacted negatively with an earlier version of
https://wiki.php.net/rfc/new_in_initializers, but I think the problem there
was not on the side of partials.

In any case, I'm voting no on this one: While PFA is simple on a conceptual
level, the actual proposal is complex and has lots of tricky edge cases.
Especially once you take a look at the implementation. I'm not convinced
that PFA in its full generality is justified for inclusion in PHP.

Regards,
Nikita


Would you look on this feature in a different light if the above
concerns about strict types and nullsafe calls could be clarified /
solved? Or is it about the implementation with it's complexity and
tricky edge cases?

I myself think one should take into account that this is a feature
that would make PHP stand out even more. Not being a follower of
other languages here :-)

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Björn Larsson]

Den 2021-06-02 kl. 22:16, skrev Mike Schinkel:

On Jun 2, 2021, at 1:45 PM, Larry Garfield  wrote:

Hi folks.  After much off-list discussion, iteration, and consideration, we 
have a new draft of PFA ready for review.

The URL is the same:

https://wiki.php.net/rfc/partial_function_application


Really excellent work, all!


It's a bit long because we wanted to be as precise as possible.  However, in 
short:

* Partial application creates a closure object you can use like any other.
* A ? indicates "exactly one required parameter here"
* A ... indicates "zero or more parameters here"


My only comment/request/suggestion is to consider Mark Randall's suggestion to 
use `...?` instead, for the reasons he mentioned in his email to the list:

https://externals.io/message/114157#114666 
<https://externals.io/message/114157#114666>

Plus Levi Morrison seemed to approve:

https://externals.io/message/114157#114667 
<https://externals.io/message/114157#114667>

-Mike



I second this opinion. So is the "...?" syntax something that will
be considered?

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Pipe Operator, take 2

[Björn Larsson]

Den 2021-06-07 kl. 21:00, skrev Larry Garfield:

Hi folks. Me again.

A year ago, I posted an RFC for a pipe operator, |>, aka function concatenation.  At the 
time, the main thrust of the feedback was "cool, like, but we need partial function 
application first so that the syntax for callables isn't so crappy."

The PFA RFC is winding down now and is looking quite good, so it's time to 
revisit pipes.

https://wiki.php.net/rfc/pipe-operator-v2

Nothing radical has changed in the proposal since last year.  I have updated it 
against the latest master.  I also updated the RFC to use more examples that 
assume PFA, as the result is legit much nicer.  i also tested it locally with a 
combined partials-and-pipes branch to make sure they play nicely together, and 
they do.  (Yay!)  Assuming PFA passes I will include those tests in the pipes 
branch before this one goes to a vote.



Thanks! I have been waiting for this :)

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial function application

[Björn Larsson]

Den 2021-05-11 kl. 17:38, skrev Larry Garfield:

On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:

Greetings, Internalians!

I would like to offer for your consideration another RFC, specifically
syntax for partial function application.

https://wiki.php.net/rfc/partial_function_application

It includes an implementation by Joe Watkins that is already about 95%
complete.  (There's some edge cases he's still sorting out, but all of
the typical cases should work already.)  Most of the design work comes
from Levi Morrison and Paul Crovella.  I helped out with the tests, a
few edge bits, and general instigator/nudge. :-)

Discuss.


It looks like the conversation has died down, and it's been two weeks, so 
pending any other notable feedback I'll open a vote on this RFC on Thursday or 
Friday.

--Larry Garfield


Sometimes the RFC's mentions how / if a specific feature is used in
other languages. Would it be beneficial also to this RFC?

I also think that the Introduction / Proposal paragraph could benefit
from a few lines on why this feature is needed. The "pipe" use case
further down is a good motiovation, just wondering about others.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Changes to Git commit workflow Nikita Popov

[Björn Larsson]

Den 2021-03-29 kl. 23:10, skrev Benjamin Morel:


Hi everyone,

Yesterday (2021-03-28) two malicious commits were pushed to the php-src
repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
exactly this happened, but everything points towards a compromise of the
git.php.net server (rather than a compromise of an individual git
account).



That is scary. Can you disclose the contents of the commits? Are they
specially designed to open a security hole, or to be harmful in another way?

An article from The Hacker News and a tweet from Zerodium about the 
incident:

-https://thehackernews.com/2021/03/phps-git-server-hacked-to-insert-secret.html
-https://twitter.com/cBekrar/status/1376469666084757506

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Phasing out Serializable

[Björn Larsson]

Den 2021-03-23 kl. 18:19, skrev Nikita Popov:

On Tue, Mar 23, 2021 at 5:01 PM Nicolas Grekas 
mailto:nicolas.grekas%2b...@gmail.com>> 
wrote:


Hello Nikita,


Picking up a loose thread:
https://wiki.php.net/rfc/custom_object_serialization

introduced a
replacement for Serializable in PHP 7.4, so it's time to think
about
deprecating and removing the old mechanism:

https://wiki.php.net/rfc/phase_out_serializable


This RFC follows a rather conversative approach. In PHP 8.1
there will be a
deprecation warning if Serializable is implemented without also
implementing __serialize() and __unserialize(). In PHP 9.0,
support for
Serializable is dropped internally, and only the interface
retained. In PHP
10.0 the interface is dropped as well.



Reading the comments in this thread, the three-step approach is
surprising to some.
What about deprecating in 8.1 and removing in 9.0 instead?
The stub Serializable interface can be provided in userland via a
polyfill, if anyone really needs a smoother transition plan.

I'd really like to see this deprecation in 8.1, to stop ppl from
writing new implementations of Serializable asap.


I've updated the RFC to follow this suggestion. Björn, please tell me 
whether this addresses your concerns.


Regards,
Nikita


Yes it does, very good!

r//Björn L

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

[Björn Larsson]

Den 2021-03-22 kl. 15:58, skrev Ben Ramsey:

On Mar 22, 2021, at 04:24, Nikita Popov  wrote:

Hi internals,

It's time for another deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_1

This is a collection of minor deprecations that various people have put
together over the last ~2 years. This RFC was formerly targeted at PHP 8.0,
but was delayed to PHP 8.1 to reduce the amount of changes necessary for
PHP 8.0 compatibility.

As usual, each deprecation will be voted in isolation.

As we're still early in the release cycle, it's still possible to add
additional deprecation candidates, given reasoning for the deprecation, as
well as available alternatives.

Of course, if there are compelling technical reasons why something should
not be deprecated, we can move things into the "Removed from this proposal"
section, in which case it will serve as documentation why some
functionality should not deprecated.



Given Rowan’s thread [1] on `utf8_encode()` and `utf8_decode()`, should we
consider adding these functions to this list or mentioning them in this
RFC as being handled separately?

Cheers,
Ben

[1] https://externals.io/message/113645


In order for that I think a clearer / better motivation is needed.

For instance bug reports or community / documented feedback that these 
functions are giving rise to problems / are misused.


Maybe also a checking how frequently thay are used in different Open 
source libraries. Found several occurences in the Revive ad server.


r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Björn Larsson]

Den 2021-03-22 kl. 14:10, skrev Sara Golemon:

On Mon, Mar 22, 2021 at 5:24 AM Rowan Tommins 
wrote:

I'm strongly against any concept of "indefinite deprecation". I consider
any deprecation notice a commitment to remove the feature in the future,
even if a specific timeline for that removal is not given.



I don't feel strongly about indefinite deprecation.  If you wanna nuke it
in 9.0, have fun.  I'm just saying I don't necessarily see the need to do
so.  The problem being addressed here is that *some* users of this function
are probably misusing it, so it's worth putting guiderails on.  I'm
hesitant to punish the ones who know exactly what they're doing as a result
of that well-meaning intention.


* People who just want to replace calls to utf8_decode won't want to go
through every call and make it exception safe.



Then they shouldn't use these replacements, it's not for them. It's for
people using iso-8859-1.


* People who want to write a polyfill couldn't use it, because they
wouldn't be able to recover the remainder of the string after an error
is thrown.



If you're writing a polyfill, then write a polyfill.   The polyfill for the
old functions is trivial, I could have written it a dozen times in the
course of writing this email reply.
So this replacement is also not for them.


* People who want transcoding without any optional extensions will be
disappointed to find only this one encoding supported.


This function isn't for them.It's for people using iso-8859-1.

There's a theme in here. :)


You'd effectively be adding a completely new core function just for
those people who work with Latin1 text, and are confident that it's not
Windows-1252 in disguise.



Yes.  I'm specifically addressing the people who have been using
utf8_en/decode() correctly all this time.  They shouldn't be punished for
the stupidity of others.


It's tempting to make any C1 control characters an error as well -
although technically valid in Latin1, these are very rarely used, and
it's much more likely that any bytes in that range are intended as
characters in Windows-1252. But that would feel very odd without having
a corresponding utf8_from_windows1252 function to use instead, at which
point we're into designing a whole new conversion library. And of
course, once you've got that UTF-8 string, you can't do much with it,
because PHP's native string functions are all byte-based, so you've
basically got to re-invent large chunks of ext/mbstring...



I disagree that you'd need to add utf8_from/to_windows1252 "for
completeness".  The goal isn't to provide all possible conversion
utilities.  The goal is only to not punish users by taking away a valid API
that they were using correctly (for those users who were using it
correctly).


-Sara




Think I'm one such user :-) So keeping them and improving a little would
be fine with me!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Björn Larsson]

Den 2021-03-22 kl. 12:12, skrev Rowan Tommins:

Hi Björn,

On 22/03/2021 10:28, Björn Larsson wrote:

In our case we use the utf8_decode functions to convert from UTF8 in
the client to ISO-8859-1 on the server, since the site is encoded in
latin1.

Our usage of that function is working flawlessly, so for us it's super
important to have a clear migration path with a good polyfill! 



I realise you can't speak for anyone else, but as a point of interest, 
would you be OK with a polyfill having a requirement on ext/mbstring or 
ext/iconv, or would you have a strong preference for a replacement built 
into the core (i.e. guaranteed available without any optional packages)?


Regards,



Well, both these extensions are part of our environment so I presume it
will also be so in the future.

Now if we have a polyfill dependent on these libraries it's a question
on how these libraries are maintained and that they are not EOL. Just 
speaking from a general point here. I'm in slight favour of mbstring,

since I have a small experience of it.

What's important for us is that the polyfill has a simple API and 
doesn't have any surprises / side effects. I think though there is

a case for improving these functions and keep them in the core.

We wrap these functions in one place so it's relatively easy to change 
the wrapper to accomodate new functionality in the utf8_* functions as

long as we get the same end result.

I also think one should consider which opensource libraries that are
using these functions. E.g. the Revive ad server v5.2 are using both.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Björn Larsson]

Den 2021-03-21 kl. 22:39, skrev Rowan Tommins:

On 21/03/2021 21:00, Max Semenik wrote:
Just a quick reminder that it's possible to compile PHP without 
mbstring and intl, which means that some hosts will provide PHP 
without these extensions, and some packagers make them available as 
separate packages that users can't or don't know how to install. Maybe 
we've got an opportunity to think about making these extensions 
mandatory?



It's somewhat relevant that until PHP 7.2, it was also possible for 
utf8_encode and utf8_decode to be missing, because they were in ext/xml, 
which is also optional.


Bundling mbstring sounds great, until you look into the details of 
what's in there and how it works. Its origin as a PHP 4 extension for 
handling Japanese-specific character encodings is visible in parts of 
its design - there's a lot of global state, and very little support for 
the nuances of Unicode.


Bundling intl would be great, but it's a wrapper around ICU, which is 
huge (because Unicode is complicated). I have read that incorporating 
that into core was one of the icebergs that sunk PHP 6. It's also 
extremely sparsely documented (if someone's looking for a project, it 
would be great to fill in all the manual stubs with a few details from 
the corresponding ICU documentation).


For what its worth, it seems these would be the relevant polyfills:

function utf8_encode(string $string) { return 
UConverter::transcode($string, 'UTF8', 'ISO-8859-1'); }
function utf8_decode(string $string) { return 
UConverter::transcode($string, 'ISO-8859-1', 'UTF8'); }



Regards,



In our case we use the utf8_decode functions to convert from UTF8 in
the client to ISO-8859-1 on the server, since the site is encoded in
latin1.

Our usage of that function is working flawlessly, so for us it's super
important to have a clear migration path with a good polyfill!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Björn Larsson]

Den 2021-01-28 kl. 01:31, skrev Kamil Tekiela:


I'm missing a thing here when we talk about "your code". I mean on
our
site we have third party libraries. They can typically have a release
schedule on a couple of releases each year. So all code is not up to
us to change. So how does this proposal adress that scenario when it's
not up to us to do the necessary changes? Is it e.g. a blocker to
upgrade to PHP 8.1 with exceptions vs warnings until the library
is updated?

As a side note I'm at the moment migrating our test site to PHP 8 and
the two most prominent hickups are located in a third party library:
"Undefined array key" and "Attempt to read property "value" on null"
which are warnings. Not sure how it would have been with these as
exceptions, e.g. would the test site stop running and thereby stop
testing of other parts.

And as I have said earlier, I do like exceptions! It's the migration
aspect I'm wondering about...

r//Björn L


This is a valid concern. I have thought about it for a while and I 
think that we should handle this the same way we did with PDO error 
mode change. We don't do anything special.


I really don't see a way that we could make a smoother upgrading 
experience. For users that avail of old libraries the onus is on them 
to check the library's compatibility with the new PHP version. 
Ideally, the change should have been made in PHP 8.0 where it would be 
more justifiable to change a default setting.


The good thing about mysqli error reporting compared to PDO is that 
the setting is global. If the library you are using is abandoned or 
you can't wait for the library to be updated then you can set the 
error reporting level in your own code. The only problem comes when 
you want to mix both modes in the same code, but that is a huge code 
smell anyway. This means that this change is not a blocker for the 
upgrade.


I think the proposal is good to be implemented in PHP 8.1 as it is 
now. But if anyone thinks otherwise or has any ideas on how to improve 
I would gladly take it into consideration. If there is any way that we 
could make the migration smoother then it would be great.


Kamil


Yes, this proposal would probably have been close to a no-brainer in
PHP 8.0.

I think the RFC would benefit on expanding on some of the key issues
that has been discussed, e.g. the clarification above about migration
aspects.

/r//Björn L/

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Björn Larsson]

Den 2021-01-27 kl. 17:13, skrev Björn Larsson:

Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:


Wouldn't this mean everybody would add mysqli_report() to their code?


That is the idea. That is what everyone should already have in their
codebase.

   And wouldn't this render the default of mysqli_report() entirely 
useless?


I'm sorry, but I don't follow the train of thought? Why would it make 
that

useless? You must set the correct error reporting mode anyway and that
function helps in doing so.

   Or is your idea that at a later stage you then want to create a 
warning

for manual mysqli_report() calls?


What are manual mysqli_report() calls? You either have that line in your
code or you don't. The idea that Nikita suggested is to meet your 
concerns.

The only way to figure out if your code needs an adjustment is to have a
warning emitted from any mysqli connect methods if you have not called
mysqli_report before. It would inform users that they are missing the
setting.

   No, I want to know if I have any code which needs fixing so I can 
see how
I want to change those places e.g. a duplicate key from INSERT to 
REPLACE

or whatever the correct fix is. Without the code aborting.


You can do that right now. This proposal will not make it easier or more
difficult for you to do that. Just paste 
mysqli_report(MYSQLI_REPORT_ERROR)
before mysqli_connect() and PHP will generate a warning whenever your 
SQL

throws an error.

   Otherwise the temptation is big to just add a global

mysqli_report(MYSQLI_REPORT_OFF) everywhere just in case.


I don't get what's wrong with that. This is literally what I said in the
RFC you can do if you don't want mysqli to report any errors. Whoever
doesn't want to see errors can use this line to silence them.
I would even make a counterpoint. If we set  MYSQLI_REPORT_ERROR as the
default then users will definitely silence errors and forget. The 
warning

mode is so useless and annoying that people will prefer to silence it
seeing no benefit to it. If we want this change to be useful then we 
should

make SQL errors report as exceptions by default.

Regarding Nikita's proposal: The compromise is reasonable, but this will
not be well-received by the community. Additional warnings will only 
make
things more confusing without providing outstanding benefits. If we 
want to
force people to set the error reporting mode that they want, then it 
would
be better to set a sensible default value and give a clear 
explanation in
the migration guide how to set it back to the previous value. Of 
course, I
don't hate Nikita's proposal and I might say I even like it a little 
bit,
but only in connection with exception mode as the default value. This 
way
users will not be surprised by an exception if it happens that they 
forget

to silence. But I would prefer that everyone embraced exceptions.

I'm missing a thing here when we talk about "your code". I mean on our 
site
we have third party libraries. They can typically have a release 
schedule on
a couple of releases each year. So all code is not up to us to change. 
So how

does this proposal adress that scenario when it's  not up to us to do the
necessary changes? Is it e.g. a blocker to upgrade to PHP 8.1 with
exceptions vs warnings until the library is updated?

As a side note I'm at the moment migrating our test site to PHP 8 and
the two most prominent hickups are located in a third party library:
"Undefined array key" and "Attempt to read property "value" on null"
which are warnings. Not sure how it would have been with these as
exceptions, e.g. would the test site stop running and thereby stop
testing of other parts.

And as I have said earlier, I do like exceptions! It's the migration
aspect I'm wondering about...

r//Björn L


PS And sorry for the lousy formatting in earlier response.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Björn Larsson]

Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:


Wouldn't this mean everybody would add mysqli_report() to their code?


That is the idea. That is what everyone should already have in their
codebase.

   And wouldn't this render the default of mysqli_report() entirely useless?

I'm sorry, but I don't follow the train of thought? Why would it make that
useless? You must set the correct error reporting mode anyway and that
function helps in doing so.

   Or is your idea that at a later stage you then want to create a warning

for manual mysqli_report() calls?


What are manual mysqli_report() calls? You either have that line in your
code or you don't. The idea that Nikita suggested is to meet your concerns.
The only way to figure out if your code needs an adjustment is to have a
warning emitted from any mysqli connect methods if you have not called
mysqli_report before. It would inform users that they are missing the
setting.

   No, I want to know if I have any code which needs fixing so I can see how

I want to change those places e.g. a duplicate key from INSERT to REPLACE
or whatever the correct fix is. Without the code aborting.


You can do that right now. This proposal will not make it easier or more
difficult for you to do that. Just paste mysqli_report(MYSQLI_REPORT_ERROR)
before mysqli_connect() and PHP will generate a warning whenever your SQL
throws an error.

   Otherwise the temptation is big to just add a global

mysqli_report(MYSQLI_REPORT_OFF) everywhere just in case.


I don't get what's wrong with that. This is literally what I said in the
RFC you can do if you don't want mysqli to report any errors. Whoever
doesn't want to see errors can use this line to silence them.
I would even make a counterpoint. If we set  MYSQLI_REPORT_ERROR as the
default then users will definitely silence errors and forget. The warning
mode is so useless and annoying that people will prefer to silence it
seeing no benefit to it. If we want this change to be useful then we should
make SQL errors report as exceptions by default.

Regarding Nikita's proposal: The compromise is reasonable, but this will
not be well-received by the community. Additional warnings will only make
things more confusing without providing outstanding benefits. If we want to
force people to set the error reporting mode that they want, then it would
be better to set a sensible default value and give a clear explanation in
the migration guide how to set it back to the previous value. Of course, I
don't hate Nikita's proposal and I might say I even like it a little bit,
but only in connection with exception mode as the default value. This way
users will not be surprised by an exception if it happens that they forget
to silence. But I would prefer that everyone embraced exceptions.

I'm missing a thing here when we talk about "your code". I mean on our 
site we have third party libraries. They can typically have a release 
schedule on a couple of releases each year. So all code is not up to

us to change. So how does this proposal adress that scenario when it's
not up to us to do the necessary changes? Is it e.g. a blocker to 
upgrade to PHP 8.1 with exceptions vs warnings until the library is updated?


As a side note I'm at the moment migrating our test site to PHP 8 and
the two most prominent hickups are located in a third party library: 
"Undefined array key" and "Attempt to read property "value" on null"

which are warnings. Not sure how it would have been with these as
exceptions, e.g. would the test site stop running and thereby stop
testing of other parts.

And as I have said earlier, I do like exceptions! It's the migration
aspect I'm wondering about...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Björn Larsson]

Den 2021-01-25 kl. 17:25, skrev Christian Schneider:

Am 25.01.2021 um 16:59 schrieb G. P. B. :

The BC break is totally minimal as it's a one line of code that needs to be 
added (and for all intent and purposes should already be done).


That does not change the fact that it is a BC break which should be treated 
accordingly.

You are basically advocating people should add mysqli_report(MYSQLI_REPORT_OFF) 
to their setup which will totally defeat the purpose of the change.
Or (probably more what you have in mind) that they should add 
mysqli_report(MYSQLI_REPORT_ERROR) now (to prepare for the change) and switch 
to MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT later once they know they are 
ready.
And this is exactly what I think should be done by the PHP default so people 
don't have to go through this manually.


Moreover, I'd rather we get rid of the warning modes all together as they make 
the least sense to me.
Either you're handling the failures explicitly anyway and you use the silent 
mode, or you don't and want it to throw with the exception mode.


This is where you are missing a key component: I want to go through a phase 
where I will notice parts where manual error handling (or exception handling 
after the change) is missing without having my application abort. This is what 
warnings are good for.

To some of us this is a very valuable step when upgrading.

- Chris


I fully agree on this! Just changing one line of code is not
a good enough justification, since for legacy code that could
be a change that is not needed. Think one should ask if for a
stable released product, changing on line of code incurs cost
for testing and release management. So it's not just about
changing one line of code...

When it comes to warnings vs exceptions for me the main benefit
with warning & grace period is that when migrating legacy code
the timeline is not forced by the application stopping and one
can see all the warnings generated by the app and fixing them.

But of course I fully support the overall strategy on going for
exceptions in Mysli.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Björn Larsson]

Den 2021-01-21 kl. 00:04, skrev Kamil Tekiela:

Hi Internals,

Following my earlier announcement in https://wiki.php.net/rfc/improve_mysqli
I decided to submit a dedicated RFC for the first proposal.

This RFC proposes to change the default mysqli error reporting mode to
exception mode. This change follows the same change in PDO. The RFC can be
found here https://wiki.php.net/rfc/mysqli_default_errmode

Kind Regards,
Kamil Tekiela



If I understand this correctly, does it imply that a lot of
legacy code that works today, will not work any longer and
needs to change? Like:
if ("mysqlierror") {
"error handling"
}

If so I think that like in other RFC's an investigation should
be done on how much code that is affected to assess BC impact.

Btw, I liked your proposal on how to improve prepared statements
in mysqli a lot!

Regards //Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Phasing out Serializable

[Björn Larsson]

Den 2021-01-08 kl. 00:23, skrev Björn Larsson:


Den 2021-01-06 kl. 17:51, skrev Nikita Popov:

On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson 
mailto:bjorn.x.lars...@telia.com>> wrote:


Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson
mailto:bjorn.x.lars...@telia.com>>
> wrote:
>
>> Den 2020-12-07 kl. 15:11, skrev Nikita Popov:
>>
>>> Hi internals,
>>>
>>> Picking up a loose thread:
>>> https://wiki.php.net/rfc/custom_object_serialization
<https://wiki.php.net/rfc/custom_object_serialization> introduced a
>>> replacement for Serializable in PHP 7.4, so it's time to
think about
>>> deprecating and removing the old mechanism:
>>>
>>> https://wiki.php.net/rfc/phase_out_serializable
<https://wiki.php.net/rfc/phase_out_serializable>
>>>
>>> This RFC follows a rather conversative approach. In PHP 8.1
there will
>> be a
>>> deprecation warning if Serializable is implemented without also
>>> implementing __serialize() and __unserialize(). In PHP 9.0,
support for
>>> Serializable is dropped internally, and only the interface
retained. In
>> PHP
>>> 10.0 the interface is dropped as well.
>>>
>>> Regards,
>>> Nikita
>>
>
> I had to slightly extend this RFC to also deprecate & remove the
> PDO::FETCH_SERIALIZE mode, which is based on Serializable.
Doesn't seem to
> be a big loss, as this fetch mode isn't working correctly in
the first
> place...
>
>
>> Given that 10.0 lies maybe ten years in the future if we have
a similar
>> timeline >> like for 7.0 to 8.0. Is it then realistic to have
such a
>> long-term planning? For me it feels a bit more prudent to
remove it
>> completely in 9.0.
>>
>> Otherwise +1!
>>
>
> I'd be also okay with dropping it entirely in PHP 9. That would
mean that
> there is no prior deprecation warning if you implement it
together with
> __serialize() and __unserialize() though, which is why I went
with the
> proposed timeline. From my own (technical) perspective, the
case is closed
> in PHP 9 either way, because that's where we can rip out support in
> unserialize().
>
> Nikita
>
Not sure I understand why no deprecation warning is needed in 8.1,
if removing completely in 9.0?

The current proposed timeline only removes in PHP 9.0 what was 
deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in 
mind here.


Ok, then I read it wrong, completely fine with above.


Anyway, my main objection towards the proposed timeline is not so
much about the functionality removed. It's more related with that
I think an RFC that mandates what should happen in 10.0, maybe
10 years into the future feels a bit farfetched.

Of course there could be exceptions for RFC's targeting PHP 10.0,
but then I think it should be for something big, like replacing
the SPL library etc.


I'm not sure I understand what your actual concern here is. Yes, it's 
a long-term plan, but why is that a problem? Why should long-term 
planning only be limited to major changes? Even a simple deprecation 
already works on a 5 year timeline, between deprecation and removal. 
Of course, I have no idea whether I'll still be involved with the PHP 
project in ten years time, but I suspect there will always be someone 
who enjoys deleting deprecated code to carry out the will ;)



Not sure we had RFC's earlier with a ten year lifespan. So I have
a concern about how realistic it would be ;-) The RFC is targetting
two major versions, think it would be cleaner to target only one
of them, not two.

Now we have this RFC for 8.1 and we remove it it in the first step in
9.0 followed by removing it completely in 10.0. One motive for this
as I understand it, is the <7.4 support.

Anyway, come to think on the RFC "Remove PHP 4 Constructors"
which targeted 7.0 and then it was removed completely in 8.0.
Also thinking on the 7.4 deprecation RFC, where the items was
removed in 8.0.

So is it by having this RFC targeting 8.1, we get five extra years
or is it the <7.4 support?

r//Björn L

After thinking a bit more my objection is twofold. One is the long 
timeline, targetting 10.0 and at least for me it's not clear why not 
having 9.0 as the endpoint is good enough.


Secondly, we introduce a three step approach, targetting both 8.1, 9.0 
and 10.0. Is this something that also could come into play for other 
deprecations and what is then the criteria for it?


Like the planned 8.1 deprecations:
- https://wiki.php.net/rfc/deprecations_php_8_0

r//Björn L

[PHP-DEV] Re: [RFC] Allow object keys in arrays

[Björn Larsson]

Den 2021-01-11 kl. 15:28, skrev Nikita Popov:

Hi internals,

I would like to present a draft RFC for allowing object keys in arrays:
https://wiki.php.net/rfc/object_keys_in_arrays

The specification in the RFC is incomplete, and primarily focussed on what
impact this has from an internal perspective.
https://github.com/php/php-src/pull/6588 is a draft implementation that
illustrates the necessary changes.

The primary motivation, and reason why I am looking into this now, is that
the current enum proposal is based on objects, and I consider it somewhat
important that enum values can also work as array keys.

 From a technical perspective, this also lays the groundwork for supporting
other key types in the future, e.g. if we wish to switch PHP to use
arbitrary-precision integers.

Regards,
Nikita



+1 for the feature itself, really nice! It makes the ENUM feature more 
complete.


The implementation aspects I can't judge though.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Phasing out Serializable

[Björn Larsson]

Den 2021-01-06 kl. 17:51, skrev Nikita Popov:

On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson 
mailto:bjorn.x.lars...@telia.com>> wrote:


Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson
mailto:bjorn.x.lars...@telia.com>>
> wrote:
>
>> Den 2020-12-07 kl. 15:11, skrev Nikita Popov:
>>
>>> Hi internals,
>>>
>>> Picking up a loose thread:
>>> https://wiki.php.net/rfc/custom_object_serialization
<https://wiki.php.net/rfc/custom_object_serialization> introduced a
>>> replacement for Serializable in PHP 7.4, so it's time to think
about
>>> deprecating and removing the old mechanism:
>>>
>>> https://wiki.php.net/rfc/phase_out_serializable
<https://wiki.php.net/rfc/phase_out_serializable>
>>>
>>> This RFC follows a rather conversative approach. In PHP 8.1
there will
>> be a
>>> deprecation warning if Serializable is implemented without also
>>> implementing __serialize() and __unserialize(). In PHP 9.0,
support for
>>> Serializable is dropped internally, and only the interface
retained. In
>> PHP
>>> 10.0 the interface is dropped as well.
>>>
>>> Regards,
>>> Nikita
>>
>
> I had to slightly extend this RFC to also deprecate & remove the
> PDO::FETCH_SERIALIZE mode, which is based on Serializable.
Doesn't seem to
> be a big loss, as this fetch mode isn't working correctly in the
first
> place...
>
>
>> Given that 10.0 lies maybe ten years in the future if we have a
similar
>> timeline >> like for 7.0 to 8.0. Is it then realistic to have
such a
>> long-term planning? For me it feels a bit more prudent to remove it
>> completely in 9.0.
>>
>> Otherwise +1!
>>
>
> I'd be also okay with dropping it entirely in PHP 9. That would
mean that
> there is no prior deprecation warning if you implement it
together with
> __serialize() and __unserialize() though, which is why I went
with the
> proposed timeline. From my own (technical) perspective, the case
is closed
> in PHP 9 either way, because that's where we can rip out support in
> unserialize().
>
> Nikita
>
Not sure I understand why no deprecation warning is needed in 8.1,
if removing completely in 9.0?

The current proposed timeline only removes in PHP 9.0 what was 
deprecated in PHP 8.1. Possibly I'm misunderstanding what you have in 
mind here.


Ok, then I read it wrong, completely fine with above.


Anyway, my main objection towards the proposed timeline is not so
much about the functionality removed. It's more related with that
I think an RFC that mandates what should happen in 10.0, maybe
10 years into the future feels a bit farfetched.

Of course there could be exceptions for RFC's targeting PHP 10.0,
but then I think it should be for something big, like replacing
the SPL library etc.


I'm not sure I understand what your actual concern here is. Yes, it's 
a long-term plan, but why is that a problem? Why should long-term 
planning only be limited to major changes? Even a simple deprecation 
already works on a 5 year timeline, between deprecation and removal. 
Of course, I have no idea whether I'll still be involved with the PHP 
project in ten years time, but I suspect there will always be someone 
who enjoys deleting deprecated code to carry out the will ;)



Not sure we had RFC's earlier with a ten year lifespan. So I have
a concern about how realistic it would be ;-) The RFC is targetting
two major versions, think it would be cleaner to target only one
of them, not two.

Now we have this RFC for 8.1 and we remove it it in the first step in
9.0 followed by removing it completely in 10.0. One motive for this
as I understand it, is the <7.4 support.

Anyway, come to think on the RFC "Remove PHP 4 Constructors"
which targeted 7.0 and then it was removed completely in 8.0.
Also thinking on the 7.4 deprecation RFC, where the items was
removed in 8.0.

So is it by having this RFC targeting 8.1, we get five extra years
or is it the <7.4 support?

r//Björn L

[PHP-DEV] Re: [RFC] Phasing out Serializable

[Björn Larsson]

Den 2020-12-07 kl. 16:49, skrev Nikita Popov:

On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson 
wrote:


Den 2020-12-07 kl. 15:11, skrev Nikita Popov:


Hi internals,

Picking up a loose thread:
https://wiki.php.net/rfc/custom_object_serialization introduced a
replacement for Serializable in PHP 7.4, so it's time to think about
deprecating and removing the old mechanism:

https://wiki.php.net/rfc/phase_out_serializable

This RFC follows a rather conversative approach. In PHP 8.1 there will

be a

deprecation warning if Serializable is implemented without also
implementing __serialize() and __unserialize(). In PHP 9.0, support for
Serializable is dropped internally, and only the interface retained. In

PHP

10.0 the interface is dropped as well.

Regards,
Nikita




I had to slightly extend this RFC to also deprecate & remove the
PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem to
be a big loss, as this fetch mode isn't working correctly in the first
place...



Given that 10.0 lies maybe ten years in the future if we have a similar
timeline >> like for 7.0 to 8.0. Is it then realistic to have such a
long-term planning? For me it feels a bit more prudent to remove it
completely in 9.0.

Otherwise +1!



I'd be also okay with dropping it entirely in PHP 9. That would mean that
there is no prior deprecation warning if you implement it together with
__serialize() and __unserialize() though, which is why I went with the
proposed timeline. From my own (technical) perspective, the case is closed
in PHP 9 either way, because that's where we can rip out support in
unserialize().

Nikita


Not sure I understand why no deprecation warning is needed in 8.1,
if removing completely in 9.0?

Anyway, my main objection towards the proposed timeline is not so
much about the functionality removed. It's more related with that
I think an RFC that mandates what should happen in 10.0, maybe
10 years into the future feels a bit farfetched.

Of course there could be exceptions for RFC's targeting PHP 10.0,
but then I think it should be for something big, like replacing
the SPL library etc.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Short-match

[Björn Larsson]

Den 2020-12-14 kl. 22:23, skrev Sara Golemon:

On Mon, Dec 14, 2020 at 2:24 PM Doug Nelson  wrote:


Both you and Sara at different points have talked about thinking was bad
practice, but I've not read anything compelling about why it should be
considered as such.



I'm not a full -1 on the concept (especially as match(true) has the
convenience of returning a value), but it's very square peg in a round hole
to me.

At the end of the day though, that's a style choice and not one I have any
business imposing on anyone, and certainly within the context of this diff,
the actual change is trivial.  It's sugar for match(true) that looks like
match.  /shrug

I might suggest broadening the scope to include `switch` as well though.
If we're going to codify match(true) as a pattern, we should at least be
consistent about it.

-Sara



I think it's a good point to keep it consistent with switch,
i.e. if moving forward make the same change in switch. Then
when mixing and matching on at least don't need to remember
where true is needed...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Phasing out Serializable

[Björn Larsson]

Den 2020-12-07 kl. 15:11, skrev Nikita Popov:


Hi internals,

Picking up a loose thread:
https://wiki.php.net/rfc/custom_object_serialization introduced a
replacement for Serializable in PHP 7.4, so it's time to think about
deprecating and removing the old mechanism:

https://wiki.php.net/rfc/phase_out_serializable

This RFC follows a rather conversative approach. In PHP 8.1 there will be a
deprecation warning if Serializable is implemented without also
implementing __serialize() and __unserialize(). In PHP 9.0, support for
Serializable is dropped internally, and only the interface retained. In PHP
10.0 the interface is dropped as well.

Regards,
Nikita


Given that 10.0 lies maybe ten years in the future if we have a similar 
timeline
like for 7.0 to 8.0. Is it then realistic to have such a long-term 
planning? For me

it feels a bit more prudent to remove it completely in 9.0.

Otherwise +1!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Björn Larsson]

Den 2020-12-01 kl. 20:57, skrev Stanislav Malyshev:


Hi!

Is a warning fine because null bytes indicate a potential attack as 
in no

sane context should null bytes be passed around?


A warning is fine because it does what it's supposed to do - fails the 
is_file check (which is literally only there to check if this string 
specifies a valid filename) while not breaking the app. Exception 
breaks the app.


So what we'll be seeing very soon is people creating userspace 
safe_is_* wrappers that would work around this "functionality", 
working against the language instead of being helped by it. This is 
not how it should be.


One could add that here the PHP programmer need to do work that basically
replicate how the code worked earlier for little gain. Maybe one also 
need to

take into account how likely it is that \0 is part of a filename.

So I wonder how much of a hurdle it is for PHP 8 migration? Especially 
of one

has an application that needs to run on both PHP 7.x and PHP 8.

Think it would be good if a solution / conclusion is found for PHP 8.0.1.

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.0.0 Released!

[Björn Larsson]

Hi,

Congratulation to the PHP core team, contributors and community
for making this release happen!! The development of PHP has for
sure been exciting in recent years, looking back at PHP 7.0 release
and onwards :-)

I'm looking forward to test PHP 8 more in depth, hopefully shortly.
It will be especially interesting to see if the migration was equally
smooth, like for PHP 7. Static testing and the BC in libs we used
was then two success factors.

Regards //Björn Larsson

Den 2020-11-26 kl. 16:28, skrev Sara Golemon:


The PHP development team announces the immediate availability of PHP 8.0.0.
This release marks the latest major release of the PHP language.

PHP 8.0 comes with numerous improvements and new features such as:

* Union Types
* Named Arguments
* Match Expressions
* Attributes
* Constructor Property Promotion
* Nullsafe Operator
* Weak Maps
* Just In Time Compilation
* And much much more...

Take a look at the PHP 8.0 Announcement Addendum for more information:
https://www.php.net/releases/8.0/

For source downloads of PHP 8.0.0 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/d8d635cfb470dfa7141dc0d85d0d581d

php-8.0.0.tar.gz
SHA256 hash:
3ed7b48d64357d3e8fa9e828dbe7416228f84105b8290c2f9779cd66be31ea71
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl+9StoQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcmqeD/9MY61N9cLe63ODMRg0WcgdV9+54NxtBbNA
nz+xHpXIHJ+z7kS3uL0WMyumRM6Sc6Fs+lmiIKMXsOJ8HnuNSoykkNwTSMLB+7F7
I+W8DxBprvsmFmEV3+inEgIS2dqPd6LLvVR3VBf4QeQVIXNC51+Gs1Iah70OtMcr
MxGBgDGhyCPJEyBXqNJUlMuNLYxJ5oZi8AB0bP9ij1to24vQBUZl7l5XColqsdWE
P8KIRew9ndUivfge4kiYelMXm7aTYgjaAx6E33GOF2RnspRzmorXdQZxQj4avbAT
3L+mnhBMGJLevJeNnjfDSztO88oCSOdezyJYmeKPutm1z/wOuRQTsHMyzQaDIunj
bXyk/ih99YGvDwWjT3eh78bnEYFi0eb0zck42IUUu6Sktrk2XcexFEvOGtWPN1e7
tVPYyMlgvlFVo81AxQJRUbaItUTcsucP9i1hIPD782N+DK4nPTkG0ATZw5VLjuaa
nEr9VNyajoDOfX/lV19qrg5uO5nFX2ex4zQvu++LwpqpzRVfTrqzj0ETfpHMVU50
g+emcG9jFKl59Da32CFjzhrZl/Mv3qzKYV+v/o5r6HJjXFi48WVbfVBfQU40T8Bk
q1o11BIjBVFGGZWGNR0L5Kq7aDLGvE5lvD1f10wvF+LG32mGU4FKCAnG4kmQgsAc
7JOCylUrpA==
=jcuX
-END PGP SIGNATURE-

php-8.0.0.tar.bz2
SHA256 hash:
5e832dc37eabf10b4ea6fb3d66b72e44e7407a3b49caa5746edcf71b9d09
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl+9St0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhciYQEACfHXgl5pfhmbMg5z6sqabNtSSAz8V8NtEl
jVYYF/PdsOc0hFtvh5o8GvMbcMlOozIXMS6UWuNUnseftZTD1hYLE7qh2PwAD0hT
BTl1Zz2Xv0hVTzCcVcWM/jXgw7L+VL6d8eG+mUKYBcgKoYuzvA4Em9gY+3s8xUF3
wKm95ELIrlQmRDTQAneTTcET6YHp0cvbiMm41EAqXI0tbJ5Pm8PuzILkTqtD/VO8
YlkWRKYz5gn6zZIMVfmk5Z949dnBJP6B+c/G5UpGoSHTf4OczQw3l5PMqMWN5MBy
zfi22jdYR5S7aNW9ntZReoFFzfdvvZlLBMzW2XsfPWy+IQvVipdYZn3FZKnW+2GE
PkWk0cvBTpWee8p4g8hMToK/tyEonK2rFtLYflK7xwzQhwtjAFstVxmW9RzCdl+M
8hLedsRstC1ACdORkmTTb65OO6/JvCOfuqEz0IKmnSrJrCJQKz5nd0I3dKdf4hhQ
P3jdJOu2jZFaF7/1FiaG+ocwzhpkoOnLmXG0mtgEr2+NliGR3QKWeI7VIBWsdsZL
WxpcAO3BAjrM6Evs02nDQRX/XDIHSnidYeLAcmrZOyXFCwVktGDVwVc0tuACkFmr
P7IqrNNLx5eWBe4wuogdsYfnKTORAM23biOGjV839OB6yjOgCU1wn1/0VsEtGJ3Q
516ICRILiA==
=bZIv
-END PGP SIGNATURE-

php-8.0.0.tar.xz
SHA256 hash:
b5278b3eef584f0c075d15666da4e952fa3859ee509d6b0cc2ed13df13f65ebb
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl+9St0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvGAEACHchUuMQqQuMLmJuFxKr3N3WxNhU67EkyT
xq8+LGRCtxEgpfZehnnIB/H56Nr5zSiIOg9Ketfo7niD/K06dVoMqNNztzWi3AVJ
Q2kwvuyeTJ9G+61e8PRJhfUq+BJGC/VLNdAHJ+N66u7bazjsYD4hnyIYlQ7bUrGC
+uC93TCkemMZv1oNZkpOc0+B7BJOIcwmAaMxnTgb0dkiTrgCyeFS8ADZoqgcX2z2
RR2pZp+6RW9QdrArm8FZ0SWTCLk6sCpEMnd81OOVG/qma1abZbdreIf0oTDIqe1r
BLPF6fHEAO1frk7MBrlRIQYI5nU+8pdVO5SFRLt2cBdCVLBD/RDKdWrYNB3bYehM
qERmGUCNYxzflMWtV5Y40/VtDJhWwCQvoUt22UmCjmR/FmxnTSceWjxmMdTce2an
Y7LRYJ5zmlxj63eYu7dyaAD2F80YCTHOTih92//4pO7yZe1F+6bfvfqvR3ZP72/s
Wp9OEp5zIM7OJ+uVuaCDHP3SCr3kRMOcJICJM8HLU/03eyTW7mHq/eYWPShWmiBD
eazHEdqzaH+OgpNiZw7odk2bldDMGWGj5av7wyo/2EgwFyhNaFdy8U5nVSfEAImk
tozdJvyV7PWfnD6ZX868wo2dwFFQB57QC0h70oXjzJZwW4F/kXhiLqsx2ilUsmN3
kls9XXKpDA==
=sHJl
-END PGP SIGNATURE-



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Supports to ?:= assignment operator

[Björn Larsson]

Hi,
Den 2020-11-11 kl. 17:18, skrev David Rodrigues:


Hello!

PHP currently supports ??= assignment, as shortly to $a = $a ?? null, but
it does not supports ?:= as shortly to $a = $a ?: null.

There are some reason to that?

- https://wiki.php.net/rfc/null_coalesce_equal_operator
- https://wiki.php.net/rfc/short_ternary_equal_operator

Thanks!


Atenciosamente,
David Rodrigues


Work on this was done by Sara Golemon during 2016. I recall that
the voting was closed, see:
- https://externals.io/message/91901

Maybe time to bring it forward again for PHP 8.1?

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Is there any interest for object constructor shorthand*just for stdClass*

[Björn Larsson]

Den 2020-10-21 kl. 22:45, skrev Rowan Tommins:


On 21/10/2020 10:47, Pierre wrote:

I'd recommend that if your data is arbitrary, you can use arrays, if you
it's not, you probably always should write typed value objects



This is pretty much what I was going to say. If you have truly dynamic 
keys, then having the full set of array functions available - e.g. 
array_map, array_filter, all the variations of sort - is almost 
definitely a win. If you know the property names in advance, then 
defining them on a class is going to help you catch a lot of mistakes.



We considered arrays once when migrating our PHP 5 codebase to PHP 7, but
the cost benefit analyse didn't show any worth while business aspects. The
only thing we needed to do was to add one line with new stdClass for the
PHP 7 migration to succeed.


On 21/10/2020 10:38, Björn Larsson wrote:

One typical usecase we have is populating an object with the result
from a DB query or using an object to write to a DB. 



This is certainly common, and even has a built-in mode in PDO. 
However, I suspect that if we didn't have stdClass, we would no longer 
see the need to add it just for these use cases, because they could 
use an anonymous class instead.



True, we looked into anonymous classes as another option but it didn't
improve readability, rather the opposite.



Which brings me back to the feature request: what if rather than 
stdClass, we look for a better syntax for creating and populating 
anonymous class instances? Then you could start with a literal and add 
real object behaviour to it - add methods, implement an interface, 
constrain the type of properties, etc.


That's a very good point! We have code today that uses stdClass, so it
would probably only come into play for new code since the existing
code runs perfectly fine :-)


I think there are two problems we might want to solve there:

1. The only way to initialise the object with variables from the outer 
scope is to pass them to a constructor, which is a bit messy (although 
constructor property promotion improves things a bit, see example below).
2. There's no way to create a truly dynamic class, i.e. one with some 
or all properties determined at run-time, without extensive string 
manipulation and eval(). (Although you can simply write "$object = new 
class{}; $object->foo=42;" to add a public, untyped property).


The proposed syntax would help with (1), but not really with (2), 
since you need to know at least the _number_ of properties in order to 
write out the literal.



Examples, and some probably bad ideas, in the hope they inspire 
someone to better ideas:


// 7.4
$object = new class($foo, $foo * 2, $nextBaz) {
    public int $foo;
    public int $bar;
    public int $baz;
    public function __construct($foo, $bar, $baz) {
  $this->foo=$foo;
  $this->bar=$bar;
  $this->baz=$baz;
    }
};

// 8.0
$object = new class($foo, $foo * 2, $nextBaz) {
    public function __construct(public int $foo, public int $bar, 
public int $baz) {}

};

// Promote properties into named parameters, implicitly defining a 
constructor and passing them to it?
$object = new class(public int foo: $foo, public int bar: $foo * 2, 
public int baz: $nextBaz) {};


// Extend this to accept an array spread? Means all properties have to 
have the same visibility and type, or default to "public mixed"...
$data = ['foo' => 42, 'bar' => 84, 'baz' => 69]; // dynamic data, e.g. 
a DB result set row

$object = new class(public int ...$data) {};


Interesting alternatives!


Regards,


r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Is there any interest for object constructor shorthand *just for stdClass*

[Björn Larsson]

Den 2020-10-21 kl. 01:30, skrev Larry Garfield:

On Tue, Oct 20, 2020, at 5:53 PM, tyson andre wrote:

Hi internals,

e.g. `$x = object{key: object{'escaped-literal': $v2 }};`
(equivalent to `$x = (object)['key' => (object)['escaped-literal' => $v2]];`)

For example, in JS, non-string key literals are surrounded in `[]` to
unambiguously reference them.
Here, that could be `object{[$key]: $value, [MY_CONST]: $other}` - but
`(MY_CONST)` would also work

- https://externals.io/message/52990 was mentioned 9 years ago but
would potentially conflict with future block expression RFCs
- `object{key: $value}` is suggested here for similarity to named
arguments

Benefits:
- Shorter and more readable code - casting an array to an object is an
unintuitive and potentially hard to remember
   way to create an object literal
- Make it easier for users to use objects for generic associative data
instead of using arrays both for lists and associative data,
   in situations where it may result in more usable APIs

For example,

```
$x = new stdClass{};
$x->prop = new stdClass{};
$x->prop->a = $a;
$x->prop->b = $b;
// Could be shortened to
$x = object{prop: object{a: $a, b: $b}}
// $x = (object)['prop' => (object)['a' => $a, 'b' => $b]]
```

This proposal is only for stdClass - there was not much interest in
https://wiki.php.net/rfc/compact-object-property-assignment
and the combination of named properties and constructor property
promotion helps with the readability of other classes.

Thanks,
- Tyson

The only data structure worse than an associative array -- from the point of 
view of performance, self-documentation, or usability -- is stdClass. :-)  I 
can't recall using it in the last decade at least, and my code has been better 
for it.

Especially now with constructor promotion and named properties, I'd prefer to 
just forget that stdClass exists and encourage others to do so as well.

--Larry Garfield


Well, but for us with a legacy code base where this is heavily used
it would definitely be an improvement! It would enable a so called
stepwise refinement :-)

One typical usecase we have is populating an object with the result
from a DB query or using an object to write to a DB.

I'm also wondering how prevalent this feature is used in different
Open Source libraries.

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Björn Larsson]

Den 2020-08-14 kl. 21:23, skrev Derick Rethans:


On Fri, 14 Aug 2020, Sara Golemon wrote:


Derick was trying to be good and meet my beta3 deadline.

And I even got that date wrong by a week. Oops.


Fortunately, I gave him that deadline (while thinking RC1) knowing
some kind of bullshit like this would come up and LO AND BEHOLD here
we are.  So the good news is that we actually have a spare two weeks.
On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown 
wrote:

2. Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link:
https://github.com/theodorejb/php-src/pull/1

Glancing at beberlei's reply, I do agree that @: is coming slightly
out of left field.  However, we're using a STV system, so might as
well go wild with the options (within reason).  HOWEVER, any option
included is going to need the same care applied as you outline in #3
and #4 below.

I would like to point out that as the main premise of the RFC was that
the chosen syntax had no ending delimiter, I would say that any new
suggested syntax should have one before I would be willing to consider
adding it.


I think that lack of ending delimiter is not a good enough reason to
exclude the @: syntax from the RFC and voting. Would be good to
have the community view on this in order to put this to rest!

We have the @@ syntax in the voting and of course that's natural.
Still adding the @: option would in my eyes give a more complete
view of feasible syntax choices. The far fetched ones should not
be included of course.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allow sleep() to accept non-integer values

[Björn Larsson]

Den 2020-08-11 kl. 10:53, skrev Rowan Tommins:


On Tue, 11 Aug 2020 at 08:31, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:


I am the author of https://github.com/php/php-src/pull/5961 , please
provide feedback.



This idea makes a lot of sense to me as a user (I'll leave comments on the
implementation to those with more C experience).

I'm pretty sure I've accidentally written things like "sleep(1.5)" in the
past, and think there is a strong argument for changing something here:


Another reason is that sleep(0.1); is silently accepted now (even with

strict types enabled), but the input is casted to 0 and thus producing
unexpected behaviour if the user is not aware of the current method
prototype.

Unless there are problems with the implementation, this seems like a
straight-forward win.

Regards,


Given this unexpected behaviour, one could almost see it as a bug. I think
it's worth considering if this also should be fixed in 8.0 or even 
earlier ;-)

So good to hear the RM view on this.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Null-safe property access in interpolated strings

[Björn Larsson]

Hi Ilija,

Den 2020-08-10 kl. 17:06, skrev Ilija Tovilo:


Hi Nikita


I think if it can be reasonably fixed it probably would make sense for
consistency and WTF-avoidance if anything.

Agree. I don't think the question of whether it is useful should come into
this, it's a matter of language consistency. There could be some leeway
here if we say that we have plans to deprecate the "$x->y" syntax in the
future anyway and don't want to extend it anymore -- but I don't believe we
have such plans at the present time.

So for the sake of consistency let's merge this then. As mentioned,
the BC break should be very very small. A few people have mentioned
they didn't expect it to work but when asked again they didn't feel
strongly about it.

Unless there are objections I will merge this tomorrow. A review of
the PR would also be welcome.

Ilija


I second Nikitas opinion that consistency is important here. One shouldn't
need to spend time as an PHP end user wondering why we have a special
case that doesn't work like the rest!

Good luck with merging.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Björn Larsson]

Hi Rowan,

Den 2020-07-28 kl. 10:52, skrev Rowan Tommins:


Hi Sara,

On Tue, 28 Jul 2020 at 00:24, Sara Golemon  wrote:


Given that it's a very small change, the RFC is probably not necessary, in
which case it's not too late, however I'd like some clarification about
what this actually offers over defaulting to 1.0.



That's a very reasonable question. The way I see it is this:

The risk of advertising 1.0 by default is that some software will have been
programmed to outright refuse that protocol version. I don't know of any
recent examples, but this bug report from 2007 was for a SOAP endpoint that
returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
Notably, Dmitry's patch for that bug made sure the protocol context option
is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
of PHP 5.3.

The risk of advertising 1.1 by default is that some software will respond
with a more complex response, and trigger some bug in our response parsing.
This was previously the case with detecting "Transfer-Encoding: chunked"
headers, for instance. By advertising 1.0, we may be benefitting from
servers "downgrading" their response.

In practice, a large amount of software appears to do neither, and simply
replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
about "advertising" versions - in practice, the code is always acting as an
HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
Transfer-Encoding, because it's increasingly rare for a server to actually
honour the 1.0 spec.

My main motivation for the change is that if someone was writing the
feature today, I don't think it would occur to them to default to 1.0, and
I think _new_ users would be less surprised at needing to opt into 1.0 than
into 1.1.

Regards,



I think there is also a consistency argument to make here. If the code
behaves like HTTP 1.1, I think it also should advertise it as such. So go
for it!

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Ternary associativity

[Björn Larsson]

Den 2020-07-23 kl. 17:26, skrev Sara Golemon:


On Thu, Jul 23, 2020 at 7:26 AM Nikita Popov  wrote:


PHP currently has an incorrect right-associative ternary operator. In
https://wiki.php.net/rfc/ternary_associativity the use of nested ternaries
was deprecated, and was supposed to become an error in PHP 8.0.

Concurrently with that proposal
https://wiki.php.net/rfc/concatenation_precedence made a very similar
change to the concatenation operator precedence. The difference here is
that this throws a deprecation notice in PHP 7.4 (same), but changes the
behavior in PHP 8.0 (rather than making it an error).

This is a pretty nonsensical outcome, in that the same type of change is
implemented in two different ways. I think it would be good to handle the
ternary change the same way as the concatenation change, i.e. make
ternaries use the correct left-associative behavior in PHP 8.0, rather than
throwing an error.

Disagree.  Consistency is valuable, but the overlap of misusage is

different.

A stacked right-associative ternary will still give a "good" result in the
sense that it's reliably reproducible and meaningful in its output based on
being written for right-associativity.
A concat mixed with other binary ops (e.g. math ops) will NOT typically
give a "good" result since the string being contacted to the numeric then
having its math op applied will result in a nonsense answer at best.

It made sense for the concat change to favor "fixing" old code in ways that
doesn't apply to stacked-ternaries since a similar "fix" there will more
likely be a break.

Strong -1 from me.
-Sara


Would it then make sense to have it as compile time error in 8.0 and
make it right-associativein in e.g. 8.1?

OTOH, when looking in RFC on top 1000 affected composer packages
it looks like having the change in 8.0 might be a way forward...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Björn Larsson]

Den 2020-07-14 kl. 15:48, skrev Nikita Popov:

On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov  wrote:


On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov  wrote:


On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski  wrote:



On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov 
wrote:


Hi internals,

I think it is well known that == in PHP is a pretty big footgun. It
doesn't
have to be. I think that type juggling comparisons in a language like
PHP
have some merit, it's just that the particular semantics of == in PHP
make
it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
returns true.

I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
and other non-strict comparisons, when used between a number and a
string:

https://wiki.php.net/rfc/string_to_number_comparison

The tl;dr is that if you compare a number and a numeric string, they'll
be
compared as numbers. Otherwise, the number is converted into a string
and
they'll be compared as strings.

This is a very significant change -- not so much because the actual BC
breakage is expected to be particularly large, but because it is a
silent
change in core language semantics, which makes it hard to determine
whether
or not code is affected by the change. There are things we can do about
this, for example the RFC suggests that we might want to have a
transition
mode where we perform the comparison using both the old and the new
semantics and warn if the result differs.

I think we should give serious consideration to making such a change.
I'd
be interested to hear whether other people think this is worthwhile, and
how we could go about doing it, while minimizing breakage.


I generally like the direction and think we should seriously consider it.

I think that before we make any decisions on this, or even dive too deep
into the discussion - we actually need to implement this behavior,
including the proposed INI setting you mentioned we might add in 7.4 - and
see what happens in some real world apps, at least in terms of potential
danger (as you say, figuring out whether there's actual breakage would
require a full audit of every potentially problematic sample.  Ultimately,
I think there's no question that if we were to start from scratch, we'd be
going for something along these lines.  But since we're not starting from
scratch - scoping the level of breakage is key here.

Zeev


Totally agree that assessing the amount of breakage in real code is key
here. I have now implemented a warning for PHP 7.4 (for now unconditional,
no ini setting) that is thrown whenever the result of a comparison is going
to change under the currently proposed rules:
https://github.com/php/php-src/pull/3917

I've done a few initial tests by running this against the Laravel,
Symfony and pear-core. The warning was thrown 2 times for Laravel, 1 times
for Symfony and 2 times for pear-core. (See PR for the results.)

Both of the warnings in pear-core pointed to implementation bugs. The
Symfony warning was due to trailing whitespace not being allowed in numeric
strings (something we should definitely change). One of the Laravel
warnings is ultimately a false-positive (does not change behavior), though
code could be improved to avoid it. I wasn't able to tell whether the other
one is problematic, as it affects sorting order.

I have to say that this is a lot less warnings than I expected. Makes me
wonder if I didn't make an implementation mistake ^^

Regards,
Nikita


As we're moving closer to PHP 8 feature freeze, I want to give this RFC a
bump. I've updated the text to account for some changes that have happened
in the meantime, such as the removal of locale-sensitivity for float to
string conversions.

It's been quite a while since we discussed this last, and back then the
discussion was fairly positive. Some experiments with a warning mode also
showed that the impact, at least in framework/library code, appears to be
fairly low in practice, contrary to what one might intuitively expect.

Now would be the time to decide whether or not we want to pursue this
change for PHP 8.


And then there was silence...

I think I'll just put this up for vote on Friday, and we'll see what people
think :)

Nikita


Seems like a very good idea!! Especially in conjunction with the RFC:
- https://wiki.php.net/rfc/saner-numeric-strings

Btw, in the RFC there is a reference to the "Trailing whitespace in numeric
strings" RFC. Update to reference "Saner numeric strings" RFC instead?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe operator

[Björn Larsson]

Den 2020-07-14 kl. 10:51, skrev Ilija Tovilo:


Hi Markus


https://wiki.php.net/rfc/nullsafe_operator

Would this still work together with short-circuiting and the null
coalesce operator?

$country = $session?->user?->getAddress()?->country ?? 'defaultCountry';

Yes, your example will still work, this is solely about references :)

Ilija


When I see this I come to think about if this might have helped
with upgrading to PHP 7 from PHP 5 due to the RFC:
- https://wiki.php.net/rfc/counting_non_countables

Like:
$value = $countvalue?->count($countvalue);

Even if I solved over 90% replacing count with empty there could
be a few more places where this might prove handy. So +1 on this!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings (again)

[Björn Larsson]

Den 2020-06-24 kl. 15:40, skrev G. P. B.:

Greetings internals,

I want to bring back the following RFC, written by Andrea Faulds, back to
the discussion table: https://wiki.php.net/rfc/trailing_whitespace_numerics

As she doesn't have time to move forward with it she allowed me to take it
over.

I've rebased her patch onto master in the following pull request:
https://github.com/php/php-src/pull/5762

As the vote is mostly straightforward I intend on opening the vote in 2
weeks.

Best regards

George P. Banyard


Excellent news! I was just waiting for this RFC to show up in due time 
for 8.0 :)


r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Björn Larsson]

Den 2020-06-23 kl. 10:30, skrev Ilija Tovilo:


Hi Björn


I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2

Absolutely so. I was thinking of the case mentioned in v1 RFC when it's used
as a stand-alone expression.
match ($y) {
...
};
   ` Optional?

In this RFC the semicolon is required. Many people thought the grammar
rules for the optional semicolon were confusing which is why I dropped
that feature in this RFC.

Ilija


Ok, thanks for the clarification. The reason for me to bring
this up is that I was pondering on if this is the only place in
PHP where a semicolon is required after a curly bracket
when not used in an expression.

If so I a counter argument could that it it is confusing for
programmers, not so privy to all the ins and outs of PHP.
Anyway, maybe a feature to consider for a future 8.1 RFC.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Björn Larsson]

Den 2020-06-22 kl. 18:05, skrev Benas IML:


On Mon, Jun 22, 2020, 6:35 PM Björn Larsson 
wrote:


Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:


Hi Björn


I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2

Well one could argue that when working with legacy code containing
switch statements where one gradually migrates to match, it might be
easier to have the same separator, i.e. ":".

I think that's somewhat of a moot point. The syntax of match is quite
different (match instead of switch, no case, no break, colon instead
of case, comma instead of semicolon, trailing semicolon). Just making
one of those the same doesn't make a meaningful difference for ease of
migration.

Agree on that! One thing though. Is semicolon mandatory or is it optional
like in the first RFC? Feels a bit odd with a semicolon after a curly
bracket.


It's mandatory since it's an expression, not a block. Another example of an
expression would be a closure:

```
$fn = function () {
 ...
}; // a semicolon is mandatory here.
```


Absolutely so. I was thinking of the case mentioned in v1 RFC when it's used
as a stand-alone expression.
match ($y) {
...
};
 ` Optional?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

[Björn Larsson]

Hi Nikita,

Den 2020-06-19 kl. 12:32, skrev Nikita Popov:

On Tue, Jun 9, 2020 at 3:33 PM Nikita Popov  wrote:


On Tue, May 12, 2020 at 10:26 AM Nikita Popov 
wrote:


On Wed, Mar 11, 2020 at 10:50 AM Nikita Popov 
wrote:


Hi internals,

Userland classes that implement Traversable must do so either through
Iterator or IteratorAggregate. The same requirement does not exist for
internal classes: They can implement the internal get_iterator mechanism,
without exposing either the Iterator or IteratorAggregate APIs. This makes
them usable in get_iterator(), but incompatible with any Iterator based
APIs.


This should have said: "This makes them usable in foreach(), but
incompatible with any Iterator based APIs."

A lot of internal classes do this, because exposing the userland APIs is

simply a lot of work. I would like to add a general mechanism to make this
simpler: https://github.com/php/php-src/pull/5216 adds a generic
"InternalIterator" class, that essentially converts the internal
get_iterator interface into a proper Iterator. Internal classes then only
need to a) implement the IteratorAggregate interface and b) add a
getIterator() method with an implementation looking like this:

// WeakMap::getIterator(): Iterator
ZEND_METHOD(WeakMap, getIterator)
{
 if (zend_parse_parameters_none() == FAILURE) {
 return;
 }
 zend_create_internal_iterator_zval(return_value, ZEND_THIS);
}

This allows internal classes to trivially implement IteratorAggregate,
and as such allows us to enforce that all Traversables implement Iterator
or IteratorAggregate.


Does anyone have thoughts on this change? Mostly this is a feature for
extensions, but also user-visible in that a bunch of classes will switch
from being Traversable to being IteratorAggregate.

We may also want to convert some existing Iterators to
IteratorAggregates. For example SplFixedArray currently implements
Iterator, which means that it's not possible to have nested loops over
SplFixedArray. We could now easily fix this by switching it to use
IteratorAggregate, which will allow multiple parallel iterators to work on
the same array. Of course, there is BC break potential in such a change.

There's some bikeshed potential here regarding the class name. I picked
"InternalIterator" as an iterator for internal classes, but "internal
iteration" is also a technical term (the opposite of "external iteration"),
so maybe that name isn't ideal.


Unfortunately this bikeshed remains unpainted... The proposed names were:

  1. InternalIterator
  2. ZendIterator
  3. IteratorForExtensionClassImplementations
  4. EngineIterator

I'm somewhat partial to the third option, with a less verbose name:
IteratorForExtensions.


I went ahead and changed the implementation to use IteratorForExtensions.
Is anyone overly unhappy with that one?

@Michal: "ExtensionsIterator" to me sounds like an iterator that iterates
over extensions.

Regards,
Nikita


I'm actually in favour of the term InternalIterator like you first
proposed. Internal and external iteration is clearly something
different, so no need due to these to shy away here ;-)

And today this iterator will be for extensions, but if somehow
that would change in the future (which I don't think), option
3 is not ideal.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Björn Larsson]

Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:


Hi Björn


I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2

Well one could argue that when working with legacy code containing
switch statements where one gradually migrates to match, it might be
easier to have the same separator, i.e. ":".

I think that's somewhat of a moot point. The syntax of match is quite
different (match instead of switch, no case, no break, colon instead
of case, comma instead of semicolon, trailing semicolon). Just making
one of those the same doesn't make a meaningful difference for ease of
migration.

Agree on that! One thing though. Is semicolon mandatory or is it optional
like in the first RFC? Feels a bit odd with a semicolon after a curly 
bracket.

Is the proposed => separator inspired by Rust or Scala? Checked what
other languages used and  for switch it's ":" of course. So one might
argue that to align with match statements in other languages "=>" is
a good choice, but OTOH if ones sees match as an enhanced switch,
having ":" as a separator is another alternative.

Since nobody else asked for it, just for you I compiled a list of
other languages :)

https://gist.github.com/iluuu1994/11ac292cf7daca8162798d08db219cd5

The conclusion: Most languages also use some form of arrow. It makes
sense to me to stay consistent with those languages.

Ilija


I think this is a very good motivation on why select => as a symbol and
I'm glad it's listed in the RFC.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Discussion] Change terminology to ExcludeList

[Björn Larsson]

Den 2020-06-16 kl. 14:14, skrev Michał Brzuchalski:

Hi Internals,

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.

The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist

Discussions should remain on the list.
Any emails sent directly are likely to be replied to on the list.

Cheers,
Michał Marcin Brzuchalski


Hi,

Some comments:
- I miss from this RFC how it affects documentation if any and with that
  how it affects translation of the documentation. So even if it's a small
  effort to change a few lines in the INI file, it might be bigger 
doing it in

  the documentation and also come up with good translations to other
  languages.
- I assume that there is a limited amount of people working with INI files,
  primarily sysadmins and to some degree developers and they are not
  doing it everyday. So is it fair to assume that it's a limited amount of
  people working with INI files and they are not doing it every day?
- In a hosting environment where this INI file lives it's fair to assume 
that
  multiple versions of PHP are hosted, e.g. today it can be both 5.6 
and 7.x.

  So for the sysadmin there will be different names for same functionality
  in the INI file when 8.0 comes out.
- As a side note, the default version shipped with the recent CentOS 7.8
  version, it's PHP 5.4.

I also think it's a bit premature to jump on this wagon for several reasons.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Björn Larsson]

Den 2020-06-16 kl. 18:17, skrev Ilija Tovilo:

Hi Björn


I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2

I do like this RFC and have one comment. Would it be suitable
to have : as a separator instead of =>?

`=>` is usually used in combination expressions (arrays, yield, arrow
functions). `:` is mostly used for switch cases and the alternative
control structure syntax [1]. `=>` also visually separates the
condition and expression better IMO. This has been suggested once
before but that's not enough for me to change it at this point.


Well one could argue that when working with legacy code containing
switch statements where one gradually migrates to match, it might be
easier to have the same separator, i.e. ":".

Is the proposed => separator inspired by Rust or Scala? Checked what
other languages used and  for switch it's ":" of course. So one might
argue that to align with match statements in other languages "=>" is
a good choice, but OTOH if ones sees match as an enhanced switch,
having ":" as a separator is another alternative.

Anyway, I think it would be good if the RFC is updated with what other
languages uses, since that is a good motivation for why using "=>" as a
separator. What bothered me a little with that selection is the usage
of the "=>" symbol for other things in PHP. Hint, I was a fan of the
"==>" for arrow functions ;-)

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Björn Larsson]

Den 2020-06-06 kl. 00:09, skrev Ilija Tovilo:


Hi internals


I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2

Small reminder: Two weeks have passed since I announced the match v2
RFC with little new discussion. I'll leave it open for another two
weeks and put it to a vote then if there are no objections. I will
send another reminder one day before I do.

Ilija


Hi,

I do like this RFC and have one comment. Would it be suitable
to have : as a separator instead of =>?

When reading the Future scope of the RFC I noted that arrow
functions was part of that, so are we here overloading the usage
of the '=>' symbol?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Unbundle ext/xmlrpc

[Björn Larsson]

Den 2020-05-11 kl. 11:16, skrev Nikita Popov:
On Mon, May 11, 2020 at 11:00 AM Björn Larsson 
mailto:bjorn.x.lars...@telia.com>> wrote:


Den 2020-05-11 kl. 08:57, skrev Christoph M. Becker:

> On 26.04.2020 at 15:28, Christoph M. Becker wrote:
>
>> I propose to unbundle ext/xmlrpc, and written a respective RFC:
>>
>> <https://wiki.php.net/rfc/unbundle_xmlprc>
> Thanks for the feedback so far.  Unless there are further issues
> regarding the RFC to be discussed, I'll open voting tomorrow.
>
> Thanks,
> Christoph

For sure it makes sense to unbundle it! However, I recall the
discussion
that was held around unbundling of ext/wddx that was about PECL
becoming a graveyard for unmaintained extensions. Is any of that
also applicable here, e.g. secondary voting option?

- https://externals.io/message/103164#103209


To be clear, the secondary voting option you're suggesting is whether 
to deprecate the extension in PECL?


I believe the RFC already addresses the question, and I agree with the 
reasoning where. Unlike the move of wddx to PECL, which was partially 
made because we had specific security concerns with the extension, our 
primary concern here is maintenance. There does not seem to be a 
strong need to signal that people should stop using it ASAP. The 
extension (and more importantly, the underlying library) has been 
unmaintained for many years already and the move to PECL will not 
change things materially in that regard.


Nikita


That was exactly my concern, i.e. to deprecate it or not. I was
seeing deprecation also as a signal about quality, not just if
there was a security issue. OTOH, maybe that's obvious when
looking at the changelog in the future.

r//Björn L

[PHP-DEV] Re: [RFC] Unbundle ext/xmlrpc

[Björn Larsson]

Den 2020-05-11 kl. 08:57, skrev Christoph M. Becker:


On 26.04.2020 at 15:28, Christoph M. Becker wrote:


I propose to unbundle ext/xmlrpc, and written a respective RFC:



Thanks for the feedback so far.  Unless there are further issues
regarding the RFC to be discussed, I'll open voting tomorrow.

Thanks,
Christoph


For sure it makes sense to unbundle it! However, I recall the discussion
that was held around unbundling of ext/wddx that was about PECL
becoming a graveyard for unmaintained extensions. Is any of that
also applicable here, e.g. secondary voting option?

- https://externals.io/message/103164#103209

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

[Björn Larsson]

Den 2020-01-21 kl. 18:16, skrev Nikita Popov:

On Wed, Jan 8, 2020 at 1:23 PM Björn Larsson 
wrote:


Den 2020-01-07 kl. 21:57, skrev George Peter Banyard:

Greetings internals,

I would like your input on adding TypeError and ValueError exceptions
to the count() function in respect to the Consistent type errors for
internal functions RFC [1], the initial PR [2] was denied as null was
not accepted as a value when it seems to be prevalent to use count()
as a substitute for isset() (this is currently done in the test runner
for php-src), although a "type error" warning was already emitted with
null.

So I've made an adjustment by still accepting null but deprecating it's
usage. An other option is to allow null as a value that always return 0.

I've also added a ValueError exception on invalid modes.
The new pull request is located at

https://github.com/php/php-src/pull/4940

Any comments would be appreciated.

Best regards and happy new year.

George Peter Banyard

[1] https://wiki.php.net/rfc/consistent_type_errors
[2] https://github.com/php/php-src/pull/4572

Hi,

My take on this is that when converting a legacy code base from
PHP 5.2 to PHP 7.4, the RFC Counting of non-countable objects
generated quite a lot of hassle. Count was used for checking
return of DB values. Code piece could e.g. look like:
for($i=0; $inrOfComments =
$blog->getNumberOfComments($blog_result[$i]->id);
}

If I read this correctly, with warnings today as is, the code after
will continue, but with exception I presume execution will stop
(unless I catch it  of course).

I still have warnings to weed out from legacy code but also
from Smarty library. So I wonder what impact this change
will have? I mean, I can live with the warnings fixing code
bit by bit...

r//Björn L


In the cases you encountered, do you know what type count() was used on?
Was it null? false? Or something else?

Nikita



It was null for in-house developed code. There is also an issue with
the Smarty count variable modifier, some work remains here.

It was developed using PHP 5.2 and today we run it on PHP 7.4. As
a side note the other most prevalent warning was:
- Creating default object from empty value in...
Due to code pattern below, with  "new stdClass" missing:
- $fields->content = isset($_POST['content']) ? $_POST['content'] : '';

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

[Björn Larsson]

Den 2020-01-07 kl. 21:57, skrev George Peter Banyard:

Greetings internals,

I would like your input on adding TypeError and ValueError exceptions
to the count() function in respect to the Consistent type errors for
internal functions RFC [1], the initial PR [2] was denied as null was
not accepted as a value when it seems to be prevalent to use count()
as a substitute for isset() (this is currently done in the test runner
for php-src), although a "type error" warning was already emitted with
null.

So I've made an adjustment by still accepting null but deprecating it's
usage. An other option is to allow null as a value that always return 0.

I've also added a ValueError exception on invalid modes.
The new pull request is located at https://github.com/php/php-src/pull/4940

Any comments would be appreciated.

Best regards and happy new year.

George Peter Banyard

[1] https://wiki.php.net/rfc/consistent_type_errors
[2] https://github.com/php/php-src/pull/4572


Hi,

My take on this is that when converting a legacy code base from
PHP 5.2 to PHP 7.4, the RFC Counting of non-countable objects
generated quite a lot of hassle. Count was used for checking
return of DB values. Code piece could e.g. look like:
for($i=0; $i    $blog_result[$i]->nrOfComments = 
$blog->getNumberOfComments($blog_result[$i]->id);

}

If I read this correctly, with warnings today as is, the code after
will continue, but with exception I presume execution will stop
(unless I catch it  of course).

I still have warnings to weed out from legacy code but also
from Smarty library. So I wonder what impact this change
will have? I mean, I can live with the warnings fixing code
bit by bit...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-31 kl. 16:48, skrev Claude Pache:

Le 31 oct. 2019 à 15:59, Theodore Brown  a écrit :

Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing. The
latter is confusing since it's no longer clear which syntax should be
used. The same situation existed with the curly brace array/string
access syntax, which was deprecated in PHP 7.4.


Yeah, curly brace string access syntax were deprecated in PHP 7.4, and it was 
IMO an error. Last day, I reviewed an old library (PHPMarkdown), whose 
algorithm (probably directly ported from the original markdown written in Perl) 
was not very readable. Replacing all $string{$index} instances with 
$string[$index] made it even less readable, because the conventional 
distinction between string indexes and array indexes used in that library (and 
in several others libraries) were lost.

Sorry for the rant. But the message is: Existence of precedent is not an 
argument, because it may be a bad precedent.

—Claude


Hi,

I think that RFC was an example where there was a clear cut case
for removing curly brace array access, but not equally clear on to
remove it for curly brace string access.

In my eyes that RFC would have benefited from having two votes,
but the baby went out with the bathwater so to speak.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes()

[Björn Larsson]

Den 2019-11-06 kl. 20:44, skrev Jakub Zelenka:

On Wed, Oct 30, 2019 at 6:33 PM Jakub Zelenka  wrote:



On Wed, 30 Oct 2019, 18:32 Jakub Zelenka,  wrote:



On Mon, 23 Sep 2019, 14:02 Nikita Popov,  wrote:


On Mon, Sep 23, 2019 at 2:52 PM Christian Schneider <
cschn...@cschneid.com>
wrote:


Hi,
I just noted (too late in the process, I know) that
openssl_random_pseudo_bytes(0) now throws an exception.

This breaks code like
 $ivsize = openssl_cipher_iv_length($method);
 $iv = openssl_random_pseudo_bytes($ivsize);
 $data = openssl_encrypt($string, $method, $key,

OPENSSL_RAW_DATA,

$iv);
if $method is 'aes-256-ecb' because $ivsize is 0.

I do realize that ECB mode ciphers are deprecated but having them

throw an

exception indirectly via openssl_random_pseudo_bytes() seems a bit

strange,

even in the context of security.

I checked the RFC
https://wiki.php.net/rfc/improve-openssl-random-pseudo-bytes and it
doesn't mention this BC break:
"False-checks on the return value of openssl_random_pseudo_bytes()

will do

nothing since the function fails closed. Usage of $crypto_strongwill
generate errors."

While I would have preferred the exception to be thrown only when

$ivsize

is not an integer or less than 0 but I guess this cannot be changed at

the

RC stage.

I would recommend though that we aim to keep BC breaks to what's

mentioned

in RFCs.


This was noted during the PR review in:
https://github.com/php/php-src/pull/3649#discussion_r230598754
Especially
in conjunction with your example, I think we should revert this part an
make openssl_random_pseudo_bytes(0) return "" without exception or
warning.
Ideally we'd adjust random_bytes() to do the same.


I agree this should be reverted for 7.4 at least as it's a BC and wasn't
really in RFC. It really doesn't matter if it's a good thing or not as it's
a BC that we shouldn't do in minor release.


I mean BC break ofc... :)


I was thinking about the revert but after reading the RFC again, I don't
think it would be right thing to do. Although it's a bit generic and
doesn't mention when it can fail, it states that the exception is thrown on
fail. We always considered this case as a fail because it returned false so
it's kind of covered. It would be also quite late to do such changes in 7.4
and I guess RM wouldn't allow it anyway. It's basically BC break that went
through the RFC which is probably acceptable.

I have to say that the RFC wasn't really well done as the implementation
followed which caused this omission. We should really look properly to the
implementation when creating RFC so it's more detailed and doesn't cause
omission like this.

Cheers

Jakub


Hi,

So, what's the RM view on this? I think one should take into
account the total amount of deprecations & BC breakages in
7.4. If they are many, it's a pity to add things making code
break even more.

Another thing to consider is that when upgrading and there
are breakages one doesn't upgrade, instead staying on an
old PHP version. So providing an easier upgrade path also
has value!

Also, is there an estimate on how this BC breakage would
affect libraries? Or to phrase it differently is it a common
code pattern that now will generate exceptions instead?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GitHub RFC workflow

[Björn Larsson]

Den 2019-11-02 kl. 17:32, skrev Nikita Popov:

Hi internals,

Now that the union types RFC is drawing to a close, I think it's time to
discuss the question of RFCs in GitHub pull requests again. Overall I'm
fairly pleased with how this went and would like to adopt the process in
some form.

In particular, I would like to start with the following fairly limited
proposal:

  * RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest.
  * After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list.
  * Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki.
  * Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.

Unlike what I had originally in mind, this keeps the PHP wiki as the ground
truth: All proposals must be moved there in entirety before voting starts.
The GitHub pull request is just a means to make it easier to iterate on the
RFC prior to arriving at the finalized proposal.

In the future we may decide to abandon this approach with very little cost
(as the actual proposals are all in the wiki), decide to adopt it more
broadly (forgoing the wiki entirely) or decide to try a different approach
(such as one repo per RFC, similar to ECMAScript RFCs).

Thoughts?

Regards,
Nikita

Hi Nikita,

I think this is a good proposal trying to achieve a balance and also 
showing some

prudence, which in my eyes don't hurt.

My impression from the RFC discussion on Github is that it was good for 
the nitty
gritty details, but getting the overall picture on the discussion was 
more difficult.


Looking back I feel it was more valuable during the discussion phase, 
but after it
I only go to the wiki to read up on the RFC. Having a threaded news 
reader also

helps catching up on old discussions (using thunderbird).

Another aspect to consider is that RFCs have a lifespan after they are 
approved,
by being used in different books, tutorials etc. Also when doing 
migrations I often
go to the wiki to check on which RFC in which release that generated 
warnings in
the code, e.g. countable RFC. I do like the simplicity and accessibility 
of the wiki.


r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-08 kl. 20:22, skrev Stephen Reay:



On 9 Oct 2019, at 01:08, Björn Larsson  wrote:

Den 2019-10-08 kl. 17:49, skrev Stephen Reay:

On 8 Oct 2019, at 22:21, Andreas Hennings  wrote:

The problem with the backtick operator syntax is that it is an obscure
but innocent-looking syntax for something that can have a huge,
perhaps devastating, impact.
It is rare enough in the field (as far as regular packages and
applications are concerned) that you can spend 5 years working with
PHP without ever learning about it. When you see it for the first
time, you will be surprised that this actually executes the code like
shell_exec(). This kind of surprise can make you shiver, and will
leave a bad taste about the language.

The " wrote:

On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis  wrote:


-Original Message-
From: Olumide Samson [mailto:oludons...@gmail.com]

it should be deprecated  for exec usage since they both do same thing

With that logic 
And we should deprecate the "print" command, since it's the same as echo.
We should deprecate 'printf', since you can just do 'echo sprintf' and, now
that I think about it, we should deprecate sprintf as well, since you can
just use vsprintf. It's a simple change too... sprintf($s,$a,$b,$c) =>
vsprintf($s,[$a,$b,$c]);. I'm just it can be done with just a simple regex
search/replace.

The fact that are SO many different ways to output text is REALLY confusing
for new developers. I think it's imperative we fix all of these items RIGHT
NOW. By doing so, I'm sure all the .NET developers that are talking smack
about PHP will suddenly denounce c# and start using PHP as well!



This isn't high cost breaking changes coz it has a verifiable, ready

alternative to upgrade to without huge Regex searches.

Since `` are used for literal strings (for poorly chosen reserved words as
field, table names (which happens from time to time)) in MySQL (multiline)
queries I doubt there is a simple way to distinguish and replace everything
to exec().

rr

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



--
Chase Peeler
chasepee...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


If a server has “scripts” that work now, and there’s no admin involved 
maintaining it (i.e. updating said scripts) - how is this going to be a 
problem? If there’s no one to maintain the script, there’s equally no one to 
update to an entirely new version of PHP either.


Couldn't it be like that the hosting provider no longer
support old PHP versions and the application is forced
up to a new version? And maybe the customer don't
have any technical staff, but needs to rent it in. Then
the least hassle the better, minimising cost.

I myself can back down to PHP 5.4 if I wanted to, but
not all hosting providers provides that luxury. I have
really appreciated the smooth upgrade path that PHP
7.x has provided even if 7.2 needed some small extra
work. 7.0 migration was also pretty smooth, so if 8.0
can repeat that it would be nice.

r//Björn L

Hi Björn,


I just want to clarify, you’re imagining a scenario where someone (a) rents a 
server that they don’t have control over (i.e. shared hosting) and (b) has some 
application running on it that is dependent on running commands via backquotes 
which (c) is unmaintained/not being updated and (d) the person renting the 
server is not technical enough to ‘fix’ the program?

Have I understood that correctly?


Cheers

Stephen


Hi,

The scenario I was thinking about is a small company where
they don't have technical staff permanently employed, more
taking it in when needed for feature updates, maintenance,
PHP upgrades etc. And cost should be kept to a minimum,
especially if there no improvements for the end customer.

The hosting provider offers a classic LAMP with basic support,
e.g. managing backups etc. And some hosting providers says
that yes, feel free to run your app on PHP 5.6 while others
say we no longer support it, we support PHP 7.1 as lowest
version.

Cheers //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-04 kl. 17:45, skrev Mark Randall:

Hi Internals,

I put forward the following RFC "Deprecate Backtick Operator (V2)" for 
discussion.


https://wiki.php.net/rfc/deprecate-backtick-operator-v2

I believe it is at least worth a discussion as to the pros and cons of 
deprecating this functionality, especially in light of the existence 
of better described and more well-known functions exhibiting identical 
behaviour.


This RFC only covers the issuing a deprecation notice, and its 
complete removal would be contained within a separate RFC.


--
Mark Randall


Hi,

I would like to bring up a point that is not unique to this RFC,
but more to deprecations in general.

For PHP 7.0 the migration at least for my company was pretty
smooth, but it was greatly helped by PHP 5.6 having extended
support. The thing was that we went from PHP 5.2 -> 5.6 -> 7.0.

Now for PHP 7.4 there was an earlier discussion this year I think
to have extended support, but it never materialised. So I believe
that one should weigh in that as it currently stands PHP 7.4 don't
have extended support, meaning it should be an even better case
to approve deprecations RFC's for 8.0.

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-08 kl. 17:49, skrev Stephen Reay:



On 8 Oct 2019, at 22:21, Andreas Hennings  wrote:

The problem with the backtick operator syntax is that it is an obscure
but innocent-looking syntax for something that can have a huge,
perhaps devastating, impact.
It is rare enough in the field (as far as regular packages and
applications are concerned) that you can spend 5 years working with
PHP without ever learning about it. When you see it for the first
time, you will be surprised that this actually executes the code like
shell_exec(). This kind of surprise can make you shiver, and will
leave a bad taste about the language.

The " wrote:

On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis  wrote:


-Original Message-
From: Olumide Samson [mailto:oludons...@gmail.com]

it should be deprecated  for exec usage since they both do same thing

With that logic 
And we should deprecate the "print" command, since it's the same as echo.
We should deprecate 'printf', since you can just do 'echo sprintf' and, now
that I think about it, we should deprecate sprintf as well, since you can
just use vsprintf. It's a simple change too... sprintf($s,$a,$b,$c) =>
vsprintf($s,[$a,$b,$c]);. I'm just it can be done with just a simple regex
search/replace.

The fact that are SO many different ways to output text is REALLY confusing
for new developers. I think it's imperative we fix all of these items RIGHT
NOW. By doing so, I'm sure all the .NET developers that are talking smack
about PHP will suddenly denounce c# and start using PHP as well!



This isn't high cost breaking changes coz it has a verifiable, ready

alternative to upgrade to without huge Regex searches.

Since `` are used for literal strings (for poorly chosen reserved words as
field, table names (which happens from time to time)) in MySQL (multiline)
queries I doubt there is a simple way to distinguish and replace everything
to exec().

rr

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



--
Chase Peeler
chasepee...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


If a server has “scripts” that work now, and there’s no admin involved 
maintaining it (i.e. updating said scripts) - how is this going to be a 
problem? If there’s no one to maintain the script, there’s equally no one to 
update to an entirely new version of PHP either.


Couldn't it be like that the hosting provider no longer
support old PHP versions and the application is forced
up to a new version? And maybe the customer don't
have any technical staff, but needs to rent it in. Then
the least hassle the better, minimising cost.

I myself can back down to PHP 5.4 if I wanted to, but
not all hosting providers provides that luxury. I have
really appreciated the smooth upgrade path that PHP
7.x has provided even if 7.2 needed some small extra
work. 7.0 migration was also pretty smooth, so if 8.0
can repeat that it would be nice.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-08 kl. 12:24, skrev Christoph M. Becker:

On 08.10.2019 at 11:44, Björn Larsson wrote:


Den 2019-10-08 kl. 11:00, skrev Claude Pache:


When evaluating the _unique_ cost of migrating legacy code, it should
be balanced with the _continual_ cost of keeping the feature. That
includes:

* People wondering what that strange syntax does, or, worse, mistaking
it with a variation of string literal.
* Difficulty to search occurrences of `shell_exec`.
* People trying to deactivate functions executing external programs
(such as `shell_exec`) using the "disable_function" ini directive,
wondering how to deactivate the backtick operator (since there is no
`disable_operator` directive).

For the third one, one idea could be to extend the current
directive also working for backticks or create a new one.
Would that be an improvement?

<https://www.php.net/manual/en/language.operators.execution.php>:

| The backtick operator is disabled when safe mode is enabled or
| shell_exec() is disabled.


Thanks, then the third point above is not valid I presume.

Cheers //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-08 kl. 11:00, skrev Claude Pache:

Le 8 oct. 2019 à 10:26, Björn Larsson  a écrit :

Den 2019-10-06 kl. 15:41, skrev Mark Randall:

On 06/10/2019 14:18, Reinis Rozitis wrote:

Since `` are used for literal strings (for poorly chosen reserved words as 
field, table names (which happens from time to time)) in MySQL (multiline) 
queries I doubt there is a simple way to distinguish and replace everything to 
exec().

Hi,

As the RFC states, there are already widely used tools available which can do 
this reliably:

https://github.com/FriendsOfPHP/PHP-CS-Fixer
backtick_to_shell_exec

--
Mark Randall


Even if there are good tools, there is a cost in doing the upgrade
not just for doing the coding work, but also testing. Assume we
have legacy code that works perfectly, so what is then the benefit
to upgrade unless it goes in together with other features?

Motivating to get a small budget to fix this in small company is
not obvious. The purity of PHP won't fly I think ;-)

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


When evaluating the _unique_ cost of migrating legacy code, it should be 
balanced with the _continual_ cost of keeping the feature. That includes:

* People wondering what that strange syntax does, or, worse, mistaking it with 
a variation of string literal.
* Difficulty to search occurrences of `shell_exec`.
* People trying to deactivate functions executing external programs (such as 
`shell_exec`) using the "disable_function" ini directive, wondering how to 
deactivate the backtick operator (since there is no `disable_operator` directive).

—Claude


That's a fair point. When it comes to the first two ones one
might wonder how much pain these has caused historically,
given that the feature has been around for a long time? Not
sure how to get hard facts on it though.

For the third one, one idea could be to extend the current
directive also working for backticks or create a new one.
Would that be an improvement?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Björn Larsson]

Den 2019-10-06 kl. 15:41, skrev Mark Randall:

On 06/10/2019 14:18, Reinis Rozitis wrote:
Since `` are used for literal strings (for poorly chosen reserved 
words as field, table names (which happens from time to time)) in 
MySQL (multiline) queries I doubt there is a simple way to 
distinguish and replace everything to exec().


Hi,

As the RFC states, there are already widely used tools available which 
can do this reliably:


https://github.com/FriendsOfPHP/PHP-CS-Fixer
backtick_to_shell_exec

--
Mark Randall


Even if there are good tools, there is a cost in doing the upgrade
not just for doing the coding work, but also testing. Assume we
have legacy code that works perfectly, so what is then the benefit
to upgrade unless it goes in together with other features?

Motivating to get a small budget to fix this in small company is
not obvious. The purity of PHP won't fly I think ;-)

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Union Types v2

[Björn Larsson]

Den 2019-09-26 kl. 10:06, skrev Nikita Popov:


On Tue, Sep 24, 2019 at 10:06 PM Sara Golemon  wrote:


On Tue, Sep 24, 2019 at 12:24 PM Claude Pache 
wrote:

The choice of supporting precisely the two literal values `null` and

`false`

is not arbitrary: They are the two values that are the most often used as
sentinel values (for indicating failure or absence). It is true that

`true` is

also sometimes used as sentinel value (more rarely and not among the
internal functions), but the same can be said of other literal values
(one of your examples includes `0`).


While I personally think `false` makes sense as an allowed "type", I also
don't want to see the union types RFC get held up on such a tiny detail.

I would propose either of the following alternatives:
1/ Remove `false` from the proposal. It can always be added at a later
time, but not taken away.
2/ Make this detail a sub-vote.  I would suggest that this sub-vote should
also be subject to a 2/3 majority in order to pass.

-Sara


This RFC is currently held up by a lack of implementation. Once that is
done, the RFC will go forward as-is (barring any novel concerns). Because I
consider it an important part of the overall proposal (*), I will neither
remove the false type, nor split it into a separate vote. People may vote
against the whole RFC if they disagree with this aspect, or any other
aspect of the proposal.

Regards,
Nikita

(*) While certainly not the primary reason for why we should support union
types, the reason why I brought this proposal forward at this time
specifically, is that the lack of union types is a blocker for my pet
project of providing comprehensive type annotations for internal functions.
Supporting "false" is strictly necessary for this purpose, because it is
part of nearly all unions as far as internal functions are concerned.


Hi Nikita,

Given the feedback on 23/9 from B Morel regarding
occurrence of true as a return value, would you then
consider adding true as a valid return type in unions?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

[Björn Larsson]

Den 2019-09-15 kl. 20:49, skrev Nikita Popov:


Hi,

Our build instructions in
https://github.com/php/php-src#building-php-source-code are currently a bit
bare... they show the basic "./buildconf && ./configure && make" cycle, but
everyone who actually tries this will quickly find out that there is a lot
more to building PHP...

Every time I compile PHP on a new system, I have to go through a pretty
long cycle of ./configure --xxx, wait until there is an error, "sudo apt
install libxxx-dev" and so on.

It would be great if someone could write up the required "apt get" and
"./configure" line to get a "reasonably large" build of PHP on a popular
Linux distro like Ubuntu 18.04, so this can be included in the README.
Something similar for MacOS would probably also be useful, where things are
even more complicated.

Bonus points for also including how to set up MySQL and Postgres in a way
that you can run mysqli/pdo_mysql and pgsql/pdo_pgsql tests. I think I lose
a couple of hours every time I try to get this working.

Anyone interested in doing this?

Regards,
Nikita


Hi,

If it's not done already I could take a swing a bit later in early October
for a Centos 7.7 distro.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Björn Larsson]

Den 2019-09-18 kl. 15:33, skrev Nikita Popov:

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov  wrote:


Hi internals,

I'd like to start the discussion on union types again, with a new proposal:

Pull Request: https://github.com/php/php-rfcs/pull/1
Rendered Proposal:
https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md

As an experiment, I'm submitting this RFC as a GitHub pull request, to
evaluate whether this might be a better medium for RFC proposals in the
future. It would be great if we could keep the discussion to the GitHub
pull request for the purpose of this experiment (keep in mind that you can
also create comments on specific lines in the proposal, not just the
overall discussion thread!) Of course, you can also reply to this mail
instead. The final vote will be held in the wiki as usual.

Relatively to the previous proposal by Bob (
https://wiki.php.net/rfc/union_types), I think the main differences in
this proposal are:
  * Updated to specify interaction with new language features, like full
variance and property types.
  * Updated for the use of the ?Type syntax rather than the Type|null
syntax.
  * Only supports "false" as a pseudo-type, not "true".
  * Slightly simplified semantics for the coercive typing mode.

Regards,
Nikita


Heads up, two weeks have passed, so this may now go to voting...

I believe relative to my original draft the main change that has happened
as a result of the discussion is the use of T1|T2|null syntax instead of
?(T1|T2) syntax for nullable types. ?T becomes an alias for T|null. People
felt fairly strongly that while ?T is a nice shorthand for a common case,
unions should use the T1|T2|null syntax that both reads better and is
already well-established from phpdoc.

I figured I should mentioned this for people who haven't been following the
GitHub thread...

Nikita



Hi Nikita,

Planned to comment on ? vs null on Github, but here it goes. Advantage
with ? syntax was in my eyes that it's clear it's not a stand-alone type or
what I should call it, but rather a "change/variant" to an existing type.

Having it stated as T1|T2|null lead it a bit in the direction of being a 
more

stand-alone type. Anyway, I'm quite happy with the proposal as it is. So
thanks for the excellent work!

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

[Björn Larsson]

Den 2019-09-18 kl. 21:44, skrev Claude Pache:


Le 18 sept. 2019 à 18:28, Nikita Popov  a écrit :

I just realized that I missed one notice here, because it is generated from
a different location: "Constant %s already defined" (The define/const will
be ignored and the previous value used.)

It would be great to have that as an exception for optimization reasons,
but as it's only a notice right now ... what do people think about
promoting it to a warning?

Nikita

Since attempting to define an already defined constant fails to perform the 
expected operation (i.e., defining the constant to *that* value), I think that 
a Warning is very reasonable.

—Claude


I also think that a warning would be appropriate here.
Have stumbled on it myself, not having notices on.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings

[Björn Larsson]

Den 2019-09-10 kl. 15:31, skrev Nikita Popov:


On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov  wrote:


Hi internals,

I think it's time to take a look at our existing warnings & notices in the
engine, and think about whether their current classification is still
appropriate. Error conditions like "undefined variable" only generating a
notice is really quite mind-boggling.

I've prepared an RFC with some suggested classifications, though there's
room for bikeshedding here...

https://wiki.php.net/rfc/engine_warnings

Regards,
Nikita


Heads up: This RFC may go to vote tomorrow.

Nikita


Hi,

I recall an issue brought up about treatment of logfiles in production 
environment

where PHP warning messages show up.

Now, this RFC reclassifies some notices to warnings and some warnings to 
errors.
Now suppose one have as a strategy to correct warnings & errors in 
logfiles, given

that this RFC will lead to new items showing up in logfiles.

Is it then worth mentioning in the RFC how this will affect handling to 
correct
warnings & errors in logfiles? E.g. face the changes and fix  it or 
write some

clever error handler to manage it or just try to suppress the new items.

Anyway, I'm in favour of this RFC since it gives a more consistent 
classification

of notices, warnings & errors.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Windows builds of PHP 7.4+ use Visual Studio 2019

[Björn Larsson]

Den 2019-06-06 kl. 14:11, skrev Christoph M. Becker:

Hi,

I like to inform you, that the official Windows builds of PHP 7.4 and
master (available from windows.php.net; currently only snapshot builds,
of course) are done with Visual Studio 2019.  While it is still possible
to build these PHP versions with Visual Studio 2017, this is no longer
tested.

This also means a small but important change, namely that we are no
longer using the "vc" prefix (e.g. "vc14", "vc15") to refer to *new*
Visual Studio versions, but rather "vs" (i.e. "vs16").  The detailed
reasoning is explained in the post titled "Visual Studio 2019
Builds"[1].  Recent beta versions of the PHP SDK are supposed to fully
support this naming change already (and particularly the renaming of the
PHP_SDK_VC environment variable to PHP_SDK_VS).  You may have to adapt
custom tooling accordingly, though.

Thanks,
Christoph

[1] 


Hi,

This is a welcome change. For beta 3 and earlier I got the error message:
$ php -v
PHP Warning:  'vcruntime140.dll' 14.11 is not compatible with this PHP 
build linked with 14.21 in Unknown on line 0


Now it works out of the box on my win 8.1 machien!
$ php -v
PHP 7.4.0-dev (cli) (built: Sep  4 2019 09:49:12) ( NTS Visual C++ 2017 
x64 )

Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

[Björn Larsson]

Den 2019-07-30 kl. 00:27, skrev Björn Larsson:


Den 2019-07-29 kl. 20:00, skrev Stephen Reay:

On 29 Jul 2019, at 22:34, Rowan Collins  wrote:

I guess what I had in mind was that *in the long-term*,
out/inout parameters would replace & parameters,
Excuse my ignorance (presumably about the complexity involved) if 
this is obvious, but if out/inout parameters are considered to be a 
better solution for the problem references generally solve (I don’t 
doubt that they are, even as a user of references), why is that 
inherently a “long term” goal? Is it not a feasible goal for next 
years release?


Cheers
Stephen


To replace current PHP way of handling parameters is for sure a
long-term goal, just imagine the BC break...

To introduce out/inout parameters without phasing out references
is probably a shorter goal to accomplish.

r//Björn L


PS I meant "replace current PHP way of handling reference parameters".

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax

[Björn Larsson]

Den 2019-07-25 kl. 14:32, skrev Nikita Popov:

On Wed, Dec 6, 2017 at 8:49 PM Nikita Popov  wrote:


Hi internals,

I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:

 https://wiki.php.net/rfc/explicit_send_by_ref

In short, while currently we have

 function byRef(&$ref) {...}
 byRef($var);

this proposal would also allow

 function byRef(&$ref) {...}
 byRef(&$var);

so that the use of by-reference passing is obvious without having to
consult the function declaration.

Regards,
Nikita


I've rebased and finished the implementation for this and would like to
move forward with this RFC.

I think it can either go forward as-is, in that it constitutes the first
step towards bringing sanity to by-reference passing in the long term. Or I
could first try to push through
https://wiki.php.net/rfc/namespace_scoped_declares or some variant thereof
so that call-site reference passing annotations can be made required on a
per-library/project basis.

As most of the feedback here has been on whether this is really worthwhile
if it's only optional, I guess the second option would be preferred?

Nikita


Hi,

I like this proposal since it gives the programmer one more tool to improve
readability and thereby quality of code.

It will also contribute to make PHP faster. So the argument that one 
shouldn't
encourage usage of references by introducing this, will then hinder 
potential

performance improvements.

The decision about how to make Namespace scoped declares can come later,
still the ongoing discussion is valuable.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

[Björn Larsson]

Den 2019-07-29 kl. 20:00, skrev Stephen Reay:

On 29 Jul 2019, at 22:34, Rowan Collins  wrote:

I guess what I had in mind was that *in the long-term*,
out/inout parameters would replace & parameters,

Excuse my ignorance (presumably about the complexity involved) if this is 
obvious, but if out/inout parameters are considered to be a better solution for 
the problem references generally solve (I don’t doubt that they are, even as a 
user of references), why is that inherently a “long term” goal? Is it not a 
feasible goal for next years release?

Cheers
Stephen


To replace current PHP way of handling parameters is for sure a 
long-term goal,

just imagine the BC break...

To introduce out/inout parameters without phasing out references is probably
a shorter goal to accomplish.

r//Björn L


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Björn Larsson]

Den 2019-07-05 kl. 03:48, skrev Theodore Brown:

On Thu, July 4, 2019 at 5:26 PM Björn Larsson  wrote:


Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:


Thanks for taking the time to push forward this RFC.

I found the earlier discussion at https://externals.io/message/104744,
which I hadn't seen. Like others, I would have chosen to keep {} for
string offsets to make it clearer, though I have not used {} in my
code for a decade. Was any consideration given to a split vote,
voting on the array and string deprecations separately?

For others interested, the history of this deprecation going back to
2005 is found at https://externals.io/message/38153

Hi,

I have the same question regarding split vote. In my eyes the
array case is a no-brainer, but for string access maybe not...


Good question. I did consider whether it would make sense to only
deprecate curly brace offset access for arrays and not strings. The
problem with this is that it wouldn't solve the issue of confusion
outlined in the RFC.

Unless the bracket syntax for string offset access was also
deprecated, users would still be left to question whether the curly
brace syntax behaves differently in certain circumstances, if one
alternative performs better than the other, if there is a scoping
related difference, or when the curly brace syntax should be used
instead of the normal bracket syntax for string offset access.



Would it be possible to compare the string access only for both
curly & straight braces and the same for array access?

I updated my script to list all the unique variable names referenced
in the output of Nikita's analysis of the top 2k Composer packages:
https://gist.github.com/theodorejb/ba35fc8f72df8823e07c5f3b51870e00.

The most frequent variable name is `$string`, and from numerous other
variable names it does seem that the majority of curly brace usages
are on strings (other frequent variable names include `$code`,
`$Bytestring`, `$chrs`, `$text`, `$str`, `$numberstring`, and many
similar examples). I also dug into the repositories for a bunch of
the packages, and most of the curly braces uses appear to be in older
code without any type declarations (which may explain why so many
variable names include a type).

Best regards,
Theodore


Hi,

Thanks for the clarification. My concern regarding the vote is that
string curly braces is swept along the vote for array curly braces,
since the last one is so obvious to deprecate. So separate votes
would make it clearer.

One could add that keeping string curly braces could help removing
confusion when reading code ;-) For instance is $var[7] an array or
string access. Having string curly braces gives the programmer one
more tool to improve readability.

r//Björn L


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Björn Larsson]

Den 2019-07-07 kl. 22:45, skrev Theodore Brown:


On Thu, July 4, 2019 at 9:13 PM Will  wrote:


Hello all,

After 15 days of discussion I have opened up voting on the following
RFC (https://wiki.php.net/rfc/add_str_begin_and_end_functions).


Thank you for your work on this. I'm surprised that so far the vote
is so controversial, with 8 votes in favor and 8 opposed.

For those voting against adding these functions, can you clarify why?
Do you dislike how they are named, or do you not see the need for the
case insensitive versions, or is there an issue with the implementation?

Personally I'd find the basic `str_starts_with` and `str_ends_with`
functions very valuable. Currently I either have to implement functions
like this myself in almost every script, or else write repetitious
code like the following:

```php
$needle = "foobar";

if (substr($haystack, 0, strlen($needle)) === $needle) {
 // starts with "foobar"
}
```

To avoid repetition, many developers use the following pattern instead:

```php
if (strpos($haystack, "foobar") === 0) {
 // starts with "foobar"
}
```

However, with longer strings this becomes far less efficient, since PHP
has to search through the entire haystack to find the needle position.

If this RFC is accepted, these awkward and inefficient approaches
could be replaced with straightforward and fast code like this:

```php
if (str_starts_with($haystack, "foobar")) {
 // ...
}
```

Please vote on the RFC if you haven't already. Clarification would be
appreciated if don't feel that these functions would be a good addition.

Best regards,
Theodore

Hi,

Having this _ci postfix is  a new way of indicating case insensitivity.
I think that it might add to negative votes. Personally I think it's a
good idea to mimic existing ways, even if they are a bit awkward.

How about using a flag or following "tradition", like stri_starts_with
& stri_ends_with or str_istarts_with & str_iends_with? That would
follow strstr / stristr and str_replace / str_ireplace.

I have no voting rights though.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Björn Larsson]

Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:

Hi Andrey,

Thanks for taking the time to push forward this RFC.

I found the earlier discussion at https://externals.io/message/104744,
which I hadn't seen. Like others, I would have chosen to keep {} for string
offsets to make it clearer, though I have not used {} in my code for a
decade. Was any consideration given to a split vote, voting on the array
and string deprecations separately?

For others interested, the history of this deprecation going back to 2005
is found at https://externals.io/message/38153

Peter


Hi,

I have the same question regarding split vote. In my eyes the
array case is a no-brainer, but for string access maybe not...

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Björn Larsson]

Den 2019-07-03 kl. 19:22, skrev Claude Pache:




Le 3 juil. 2019 à 17:59, Nikita Popov  a écrit :

On Wed, Jul 3, 2019 at 4:41 PM Levi Morrison  wrote:


Was any analysis of usage done for top open source projects? I support
this direction, but would prefer to know its current impact before
voting.


I checked top 2k projects with a 2-3 months outdated data set. Here is the
analysis log: https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e

Overall there were ~2.2k individual uses of alternative array syntax. To
put that into context, there 888.3k total array accesses in the data set,
which puts usage at about 0.25%. Uses are usually clustered, i.e. if
alternative array syntax is used in a file, it will be used many times.

Nikita

It ought to be noted that the alternative syntax is used essentially for 
strings, not for arrays proper. In fact, I expect that it is used almost 
exclusively for strings.

That means, most probably: ~2.2k uses of alternative syntax for direct byte 
access in strings among 888.3k for byte access in strings AND direct element 
access in arrays.

—Claude

Hi,

Would it be possible to compare the string access only for both curly & 
straight braces

and the same for array access?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

[Björn Larsson]

Den 2019-07-04 kl. 18:43, skrev w...@wkhudgins.info:
I have updated the RFC here 
https://wiki.php.net/rfc/add_str_begin_and_end_functions to reflect 
changes from the mailing list discussions. I will promptly open voting 
on this RFC.


-Will


Hi,

I think it would be good to include references to the Javscript & Python
functions that was referenced earlier since it was a driver for the name
change.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging

[Björn Larsson]

Den 2019-06-17 kl. 19:10, skrev Erik Lundin:

Background:
The latest version of PHP seems to handle fatal errors as exceptions 
which results in stack traces being logged. Stack traces can 
potentially contain sensitive information and should not be logged in 
a production environment.


Test code:
Jun 17 15:58:01 server php[29650]: PHP Fatal error:  Call to undefined 
function does_not_exist() in /var/www/html/index.php on line 3


PHP 7.4 (dev):
Jun 17 15:58:01 server php[18159]: PHP Fatal error:  Uncaught Error: 
Call to undefined function does_not_exist() in 
/var/www/html/index.php:3#012Stack trace:#012#0 
/var/www/html/index.php(5): handle_password('s3cretp4ssword')#012#1 
{main}#012  thrown in /var/www/html/index.php on line 3


Suggested patch:
Add a configuration value to be able to prevent exceptions from 
logging stack traces.


log_exception_trace = On/Off

It would be optimal to have this disabled as default as novice 
administrators would perhaps not be aware that this information would 
be logged. For debugging purposes it would be helpful to be able to 
enable this but maybe the default value should be set conservatively 
to minimize unnecessary problems?


I've added this configuration value in Zend/zend.c as the exception 
message is compiled in Zend/zend_exceptions.c. Adding it to 
main/main.c would change the scope from zend_compiler_globals to 
php_core_globals and I guess that you wouldn't want to mix them?


Link to pull request: https://github.com/php/php-src/pull/4281

Regards, Erik Lundin


Hi,

In our environment these kind of errors goes to the Apache error log.
We have full control of the complete LAMP stack and it's only our
ISP who can access these. So little risk for leakage of sensitive info.

Now we have a large legacy code base that has been migrated from
PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
usage of these kind of stack traces in the production environment.
It helped us fixing the (hopefully) last issues. We also have a kind of
beta site, but we didn't got enough traffic on that one to trigger the
errors we got in production.

My 50c on this subject, well aware of that having "ownership" of the
LAMP stack is one prerequisite to not disclose sensitive info.

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: default_charset and mb_internal_encoding

[Björn Larsson]

Den 2019-04-11 kl. 15:41, skrev Christoph M. Becker:

On 02.04.2019 at 11:42, Nicolai Scheer wrote:


I'm currently in the process of migrating an old application from php 5.6
to 7.2.
In the process, I fiddled with the default_charset ini setting.

The documentation states (c.f.
https://www.php.net/manual/en/ini.core.php#ini.default-charset):

"In PHP 5.6 onwards, "UTF-8" is the default value and [...] The value of
default_charset
will also be used to set the default character set for [...] and for
mbstring functions
if the mbstring.http_input mbstring.http_output mbstring.internal_encoding
configuration option is unset."

As such, I'd expect to be able to set default_charset to iso-8859-1 and
mbstring to pick that same setting for its internal encoding (if the
mentioned directives are unset, that is).

This seems not to be the case:


 confirms the reported behavior.  A quick look
at the code, too.  I suggest you file a ticket on .

Thanks,
Christoph M. Becker


Hi,

Did this lead to a bug report?

It lead to a bug in Smarty 3.1.33 for me. I got a warning about
"mbregex compile err: invalid code point value" in mb_split().
I have content in ISO-8859-1 and Smarty normal procedure to
set encoding and php.ini setting to ISO-8859-1 flunked.

However mb_regex_encoding('ISO-8859-1') did the trick!

r//Björn L


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Björn Larsson]

Den 2019-04-24 kl. 23:35, skrev Andrey Andreev:

Hello,

I personally am not happy with the outcome of the vote. I think
there's no practical benefit to be gained from the proposal and I
don't even understand what has urged the author to make it; I voted No
on both questions.

However, what's done is done and these post-vote protests are getting
ridiculous. Where were you all during discussion and even during the
voting period? I only remember a single person's rant here and barely
any comments on social media about it ... The people who voted Yes may
have weak arguments ("there's tools out there" isn't a good argument
in my book), they may've underestimated the impact of the change or
they may not even care about it. But they cared enough to drop by and
make their views count, while almost nobody cared enough to come here
and say this isn't right. We don't get to force-reverse a decision
that we didn't care enough for when it mattered.

Cheers,
Andrey.
You are absolutely right! The only excuse for myself during the 
discussion etc
was that I thought it never would pass, so I "slept"... One thing to 
consider
though is if the BC break together with other features is big enough to 
justify

extended support for 7.4?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Björn Larsson]

Den 2019-04-24 kl. 23:38, skrev Peter Kokot:

Hello,

On Wed, 24 Apr 2019 at 23:12, Björn Larsson  wrote:

Hi,

I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the 
I'm not sure if we're looking at the same libraries and versions here
but both of these use normal opening tags in the code for quite a
while:
https://github.com/revive-adserver/revive-adserver
https://github.com/smarty-php/smarty

Keywords open source, PHP, and short opening tags don't go together
anymore neither people coding in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.


Well, checking a bit closer when running the script:
grep -rin "None

seems to be critical though. 5 in the Revive case comes from including an
old Smarty 2.6.18 version from 2005.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Björn Larsson]

Den 2019-04-24 kl. 19:43, skrev Chase Peeler:

On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta  wrote:


On Wed, 24 Apr 2019, 19:25 Christian Schneider, 
wrote:


Am 24.04.2019 um 19:13 schrieb Marco Pivetta :

On Wed, 24 Apr 2019, 19:10 Christian Schneider, 
wrote:

Am 24.04.2019 um 19:01 schrieb Peter Kokot :

just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.

A friendly reminder that some people are hosting customer code which

they do not want to touch but will get support requests once the code
breaks.

- Chris

That's normal? Everyone has projects to maintain, and breaking changes

are common: they're gonna call you for one anyway: if you don't like

that,

then you are in the wrong line of business.

See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.

- Chris


Run a fixer: they are out there, and they are extremely stable too.

Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.


All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update 

Hi,

I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the http://www.php.net/unsub.php