RFC: Loop… or

La RFC Loop… or… proposait d’ajouter un bloc, optionnel, aux structures de boucles (for, while et foreach) de PHP, exécuté dans le cas où on n’entre jamais dans la boucle — la condition n’étant pas vérifiée, dès le premier passage. Ce bloc aurait été introduit par le mot-clef or, afin d’éviter d’ajouter un nouveau mot réservé.

Il est ressorti de nos échanges que la majorité d’entre nous était plutôt pour cette fonctionnalité, même si n’étions pas à 100% de oui et que plusieurs auraient aimé pouvoir utiliser else plutôt que or, ou disposer de quelque chose de plus complet répondant à plus de cas. J’ai donc posté en ce sens sur internals@.

Arrivée au moment de la phase de votes, cette RFC a été quelque peu mise de côté et elle n’a pas été acceptée. À voir si une solution plus complète, répondant à plus de cas que le seul « on n’est jamais entré dans la boucle » reviendra sur le devant de la scène dans le futur !

RFC: Suppression des tags alternatifs

La RFC Remove alternative PHP tags partait du principe que les tags alternatifs (tags « ASP » <% ou <%= et %>, ainsi que <script language="php"> et </script>) ne sont quasiment jamais utilisés — sans compter qu’ils entrent parfois en conflit avec certains langages de templating.

Nous avons été assez nombreux à échanger sur le sujet, majoritairement d’accords sur le fait que ces tags ne sont quasiment jamais utilisés et qu’il serait acceptable de les supprimer, pour ne laisser que les balises <?php, <? et <?= les plus connues. J’ai donc posté en ce sens sur internals@.

Cette RFC a été acceptée, avec une large majorité. Les tags alternatifs disparaitront donc, pour PHP 7.

RFC: Interdire l’usage de plusieurs ‘default’ dans un ‘switch’

La RFC Make defining multiple default cases in a switch a syntax error partait du constat qu’il est aujourd’hui possible, en PHP, de placer plusieurs sections default dans un bloc switch.

Par exemple, en PHP 5.6, il est possible d’écrire ceci :

$a = 10;
switch ($a) {
    case 1:
        echo "cas 1\n";
        break;
    default:
        echo "premier default\n";
        break;
    default:
        // C'est dans ce second default qu'on passe, pas dans le premier
        echo "second default\n";
        break;
}

Dans ce cas, c’est la dernière section default qui est utilisée par PHP (là où, différences d’implémentation oblige, HHVM utilise la première).

Bien sûr, les discussions sur la mailing-list php-internals@afup ont montré que nous étions tous d’accord sur le fait qu’utiliser deux cas default dans une même structure switch n’a pas de sens et devrait donc être interdit et lever une erreur de syntaxe (en PHP 7). De plus, si PHP 5.7 sort un jour, cela devrait lever un avertissement E_DEPRECATED, pour préparer l’arrivée de PHP 7.  J’ai donc posté en ce sens sur internals@.

Cette RFC ayant été acceptée quelques jours après, PHP 7 sera plus cohérent sur ce point.

RFC: Opérateur null-coalesce ??

La RFC Null Coalesce Operator proposait d’introduire un nouvel opérateur ?? qui renverrait le résultat de sa première opérande s’il existe et est différent de NULL (en comparaison stricte), et celui de sa seconde opérande sinon.

Le constant de départ était que l’opérateur ?: introduit avec PHP 5.3 est pratique, mais pas parfait : il peut notamment entrainer des levées de notices si sa première opérande n’existe pas (ce qui force souvent à utiliser isset()).

Avec le nouvel opérateur ?? proposé par cette RFC, il deviendrait possible d’écrire quelque chose de ce type, qui ne lèverait pas de notice si $_GET['user'] n’existe pas :

$username = $_GET['user'] ?? 'nobody';

Les échanges que nous avons eu sur la mailing-list php-internals@afup ayant montré que notre avis était plutôt positif et qu’un tel opérateur apporterait une valeur à PHP, j’ai posté en ce sens sur internals@.

La RFC correspondante à été acceptée et ce nouvel opérateur ?? devrait arriver avec PHP 7 !

Notons que l’ajout d’un opérateur d’affectation ??= n’a pour l’instant pas été jugé utile. Il pourra, bien sûr, être ajouté dans le futur, s’il s’avère qu’il est nécessaire.

RFC: Integer Semantics

La RFC Integer Semantics visait à améliorer la cohérence de PHP entre plate-formes différentes, en implémentant les changements suivants :

  • NaN et Infinity seraient toujours égaux à 0 lorsque transtypés en entiers,
  • les décalages bit-à-bit d’un nombre négatif de bits seraient interdits,
  • le décalage bit-à-bit vers la gauche d’un nombre de bits supérieur à la taille d’un entier donnerait toujours 0,
  • et le décalage bit-à-bit vers la droite d’un nombre de bits supérieur à la taille d’un entier donnerait toujours 0 ou -1 (en fonction du signe)

En effet, aujourd’hui, une partie de ces manipulations a un comportement qui dépend de l’architecture et de la plate-forme sur laquelle tourne PHP.

Cette RFC vise donc à uniformiser les choses, en considérant que c’est le rôle d’un langage de haut-niveau comme PHP.

Les échanges que nous avons eu sur la mailing-list php-internals@afup montrant assez bien que nous étions globalement d’accord sur le fait qu’uniformiser le langage est une bonne chose et que les développeurs travaillant avec un langage de haut-niveau ne devraient pas avoir à se soucier du type de détails que veut corriger la RFC, j’ai posté en ce sens sur internals@.

Cette RFC a été acceptée quelques jours après et le comportement de PHP 7, pour ce qui concerne quelques cas spécifiques de manipulation d’entiers, devrait donc être moins dépendant de la plate-forme sur laquelle nos applications sont exécutées.