Zenn
🐈

今週の PHP 2024-03-09 〜 2024-03-15

2024/03/18に公開
PHP
tech

PHP のメーリングリストから、気になった情報をピックアップします。

Internal

PHP: rfc:grapheme_str_split

絵文字対応の str_split である grapheme_str_splitを追加しようという提案です。
graphemeは書記素という意味です。絵文字を一つを正しく一つの書記素として分割できるということですね。

mb_str_split ではあかんのかと思ったら、あかんようです。

$ sapi/cli/php -r 'var_dump(mb_str_split("🙇‍♂️"));'
array(4) {
  [0]=>
  string(4) "🙇"
  [1]=>
  string(3) "‍" // U+200D Zero Width Joinner
  [2]=>
  string(3) "♂"
  [3]=>
  string(3) "️" // U+FE0F VARIATION SELECTOR
}

PHP: rfc:deprecate-implicitly-nullable-types

PHP8.4で暗黙的にnullableになる型を非推奨とするRFCが可決されました。

さっそく、各所で対応がなされているようです。

リリース

base64_encode without padding - Externals

base64_encodeにおいて=のパディングをオプションにしようという提案です。

RFC 4648: The Base16, Base32, and Base64 Data Encodings

通常のBase64エンコードでは、=のパディングはオプションではないため、データサイズがピッタリ出ない限りは省略不可です。URLセーフなBase64エンコードの場合は省略可能です。

今回の提案は、通常のBase64エンコードの話なので、少し話としてはチグハグな感じがします。

PHPマニュアルにもメモが書いてありますがURLセーフなBase64エンコードはユーザーランドでも下記のようなワンライナーでかけます。

function base64url_encode($data) {
  return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}

[Pre-RFC] Improve language coherence for the behaviour of offsets and containers - Externals

RFCの前に提案内容に対するフィードバックがほしいというお便り、提案内容は下記のマークダウンにかかれています。

php-rfcs/container-offset-behaviour.md at master · Girgias/php-rfcs

例えば、PHPの文字列は配列としてN番目の文字列としてアクセスすることもできます。マークダウンには下記のような記述があります。

PHP supports accessing sub-elements of a type via an offset using brackets [] with the following notation container[offset]. However, the behaviour of such accesses depends not only on the type of the container and that of the offset, but also on the operation that is being performed while accessing the offset. The existing behaviour is highly inconsistent and difficult to anticipate.

つまり、コンテイナー（文字列だったり、オブジェクトであったり）に対する配列添字のでのアクセスには一貫した仕様がなく、コンテキストによっても動作が変わってしまう。

このRFCは、そのような配列添字アクセスに対する一貫性をもたせようというもののようです。
すでに半年近くをかけてこのRFCを準備しているようなので、とにかく内容がボリューミーです。もう少しまとまってきて、具体例とかが出てくるとわかりやすくなると思います。

Discussion