September 2014 on internals@php

Cet article est aussi disponible en français.

730 messages have been exchanged in September 2014 on PHP’s internals@ mailing-list – almost the same number as in August.

As a graph representing the number of mails per month for the last three years, we’d get:

At the beginning of the month, Andrea Faulds wrote an RFC called “Implicit isset() in Shorthand Ternary Operator”. Its idea was to modify the ?: operator introduced with PHP 5.3 to automatically add an isset() and, so, prevent any notice from being raised.

The first answers indicated that the idea could be interesting, but, at the same time, several voices said changing the behavior of ?: in such a way might not be quite a good idea.

In the end, most of this RFC has been rewritten, leading to RFC: Null Coalesce Operator. The idea is now to add a new ?? operator, instead of changing the behavior of ?:. This new operator can be used like this:

// Uses $_GET['user'] if it exists -- or 'nobody' if it doesn't
$username = $_GET['user'] ?? 'nobody';

// Loads some data from the model and falls back on a default value
$model = Model::get($id) ?? $default_model;

With 31 votes “yes” and 3 votes “no”, this revamped version of the RFC has passed, which means PHP 7 will have a new ?? operator.

Leigh has written the RFC: loop + or control structure, which aims to add an optional block to PHP loops (for, while, foreach). This block would be executed in cases we don’t enter inside the loop (as the condition has not been true, even at first try). It would be introduced by the or keyword.

With this RFC, we could write something like this:

foreach (generator() as $k => $v) {
    // loop body
}
or {
    // executed if we never entered the
    // body of the foreach loop
}

This feature already exists in some templating languages – for instance, it is supported by Twig for its for loops, using the else keyword.

Note: using or would mean not adding a new reserved word, and else, which is used by other languages, cannot be used for PHP as it would lead to ambiguities in the language.

A few other things have been talked about in the conversation (we’ll see if someone pushes them farther, via other RFCs?), like the idea for a loop to systematically return the number of iterations done.

Robert Stoll suggested PHP 7 might be an occasion to make transtyping operations more strict. For example, (int)"a" would not longer be 0 and it would raise an error. Andrea Faulds quickly answered that explicit casts cannot fail and changing this behavior now would cause an incredible amount of bugs and BC-breaks.

Still, it might be possible to add some new transtyping functions that would be more strict – maybe like ext/filter already does? Another approach could be to use new keywords, like int('2'), or even a syntax close to constructors, like $a = new int('2').

Nikita Popov has written the RFC: Remove alternative PHP tags, which proposes to remove, for PHP 7, the alternative tags <% ... %> and <script language="php"> ... </script>.

Several answers have been quite positive, but others noted a script to facilitate the migration to <?php ... ?> would be helpful.

Votes have been opened a few days before the end of the month and results should be there at the beginning of October. For now, things seem to be going well for this RFC.

Levi Morrison noted that what is usually called type-hints are definitely not hints, as types fixed when declaring a function or a method are checked and an error is raised if passed parameters don’t match them. As a consequence, he asked if someone had a better name idea, or if we were going to keep calling those hints.

Andrea Faulds suggested Optional Type Declarations for parameters and Return Type Declaration for the return-type. As those types are not optional once they are set, Type Declarations might be a good compromise – or maybe Type Assertions.

On the other hands, Type Hints has been used for years in the manual and by the community… In the end, I’m curious to see if this proposal will go farther and if, one day, we’ll stop talking of hints for things that are actually not.

Tjerk Meesters noticed the tests of ReflectionFunction::isDeprecated() depend, for now, on functions flagged as deprecated – but, as those might get removed for PHP 7, these tests might have to be updated.

That test might also be fixed, so it finds a deprecated function by itself. Or, instead, would it not be interesting for PHP to define a __deprecated__() function, that would forever be flagged as deprecated – even if it would only exist when PHP is compiled in debug-mode?

During the conversation, Alexander Lisachenko noted that adding a deprecated keyword, that could be used from user-space, might be an interesting idea, especially for some big frameworks. I wonder if this idea has not already been suggested in the past…

Dmitry Stogov has written the RFC: Fix list() behavior inconsistency, which suggests to remove a few inconsistencies of list() when it comes to strings. Today, using list() on a string works, or not, depending on the situation:

list($a,$b) = "aa"; // $a and $b are NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a is 'a' and $b contains 'b'

For PHP to be more consistent, this RFC proposed to forbid using list() on strings, or to make it work in all cases. As Derick Rethans indicated, the second option would add a new behavior to PHP, while the first one would come to removing something that works today (even if not documented).

Votes have been opened right before the end of September. Considering how things are going for now, it is very likely something will be done, but it’s hard to predict which one of those two approaches will win.

I was saying last month a mailing-list had been setup for members of the French UG AFUP, to discuss, in French, about proposals that were announced on internals@.

Following our discussions of this month, I (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

• Our opinion on RFC Make defining multiple default cases in a switch a syntax error
• Our thoughts about RFC Integer Semantics
• And our summary for the addition of the new ?? operator

In addition, we now have a blog. I’ll try posting, mainly in French, about the opinions we have expressed on internals@, and, if possible, a few sentences to summarize the goal of each RFC and why we’ve spoken the way we did: PHP Internals en français

Matt Wilmas worked on a patch that would bring a micro-second resolution (with a good precision) to functions such as microtime(). It might be added to a next minor version of PHP 5.6.

Andrea Faulds opened votes on RFC: Scalar Type Hinting With Casts, before pausing them to give people more time to discuss the matter… And, in the end, the RFC has been withdrawn.

Leigh proposed adding two new format codes to pack() and unpack(), related to 64 bits. RFC: 64 bit format codes for pack() and unpack() has been posted a few days later. This RFC passed, with 15 votes “yes” and 0 votes “no”.

Here’s another RFC written by Andrea Faulds: RFC: ZPP Failure on Overflow. It started off the fact that, today, when a floatting-point number too big to fit in the range of an integer is passed as a parameter to an internal function (exposed by PHP or an extension) that expects an integer, it is received by this function as… an integer… which causes loss of data. This RFC proposes that, when an integer is expected as a parameter and the received value is a float that cannot fit in an integer, the parsing of the parameters of the function fails, and a warning gets raised.

At the beginning of the month, Levi Morrison announced votes were being opened on RFC: Make defining multiple default cases in a switch a syntax error. With 28 votes “yes” and 0 votes “no”, it passed: it will not be possible anymore, with PHP 7, to write more than one default section in a single switch construct.

In the middle of September, Andrea Faulds indicated the beginning of the voting phase on RFC: Integer Semantics. With 16 votes “yes” and 8 votes “no”, it seems this RFC passed – even if votes got closed pretty much a day too early.

Kris Craig wrote the RFC: Change checkdnsrr() $type argument behavior, to change the default behavior of checkdnsrr(), to fetch more than only MX records.

And, finally, Nicolai Scheer noticed it isn’t possible to use an object as an array key, even if it defines a __toString() method: this one is not automatically called. Calling __toString() automatically in such a situation doesn’t seem right, as this method is used by some to produce a printable version of an object. Instead, a new magic method __toKey() could be added, so __toString() continues to return a printable string, while this new method would return a more technical identifier.

internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.