Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124652
Message-ID: <1718C77D-BF28-424E-B972-5E86B79CAC37@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A1F85A9C-743B-454F-A4A6-C55991A7D651"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of
 offsets and containers
Date: Sat, 27 Jul 2024 21:50:31 +0200
In-Reply-To: <mhbeurk_htxbQxzIEs98wQoR8Xczf-L7L8aCAIVhATD7wQiEUJwpAYxYS-llyac0pN761mnQJfpVQcDUoXAgasaWpWylpt6LE-I2oM4zrbk=@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
To: "Gina P. Banyard" <internals@gpb.moe>
References: <mhbeurk_htxbQxzIEs98wQoR8Xczf-L7L8aCAIVhATD7wQiEUJwpAYxYS-llyac0pN761mnQJfpVQcDUoXAgasaWpWylpt6LE-I2oM4zrbk=@gpb.moe>
From: claude.pache@gmail.com (Claude Pache)


--Apple-Mail=_A1F85A9C-743B-454F-A4A6-C55991A7D651
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 4 juil. 2024 =C3=A0 15:52, Gina P. Banyard <internals@gpb.moe> a =
=C3=A9crit :
>=20
> Hello internals,
>=20
> I would like to formally open the discussion on an RFC I've been =
working on for the past year:
> https://wiki.php.net/rfc/container-offset-behaviour
>=20
> As DokuWiki is a bit of a faff at times, the Markdown sources are =
available on GitHub:
> =
https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour=
.md
>=20
> The implementation is basically done, other than some mysterious JIT =
issues that I haven't been able to pinpoint yet.
>=20
>=20
> Best regards,
>=20
> Gina P. Banyard

Hi,

Thanks for the RFC. Some small remarks:


1. In =C2=A7 Add granular interfaces: `DimensionUnsetable` : I would =
have written =E2=80=9Cunsettable=E2=80=9D with 2 t=E2=80=99s (like =
=E2=80=9Csettable=E2=80=9D, =E2=80=9Cunforgettable=E2=80=9D, =
=E2=80=9Cregrettable=E2=80=9D, and like =E2=80=9Cunsetting=E2=80=9D).


2. You propose to emit warnings in 8.4 for `$array[null]`, =
`$array[true]` and `$array[false]`. I argue that it should be =
deprecation notices instead. The reason is that currently no notice is =
emitted, and that there may be valid code that (implicitly or not) rely =
on the current behaviour. For example:

```php
function foo(?int $x): string {
    static $cache =3D [ ];
    return $cache[$x] ??=3D heavyCalculationForFoo($x);
}
```

and:

```php
$total_by_type =3D [ ];
foreach ($list as $row) {
    assert($row['type'] =3D=3D=3D null || is_string($row['type']) && =
$row['type'] !=3D=3D '');
    $total_by_type[$row['type']] ??=3D 0;
    $total_by_type[$row['type']] +=3D $row['amount'];
}
```

The case of `$array[null]` is similar to `strlen(null)`, deprecated in: =
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg


3. Given the new semantics, `array_key_exists()` should be amended in =
order to support objects implementing `DimensionReadable`.


=E2=80=94Claude





--Apple-Mail=_A1F85A9C-743B-454F-A4A6-C55991A7D651
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Le 4 juil. 2024 =C3=A0 15:52, Gina P. Banyard =
&lt;internals@gpb.moe&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><div>Hello internals,<br><br>I =
would like to formally open the discussion on an RFC I've been working =
on for the past =
year:<br>https://wiki.php.net/rfc/container-offset-behaviour<br><br>As =
DokuWiki is a bit of a faff at times, the Markdown sources are available =
on =
GitHub:<br>https://github.com/Girgias/php-rfcs/blob/master/container-offse=
t-behaviour.md<br><br>The implementation is basically done, other than =
some mysterious JIT issues that I haven't been able to pinpoint =
yet.<br><br><br>Best regards,<br><br>Gina P. =
Banyard<br></div></div></blockquote><br></div><div>Hi,</div><div><br></div=
><div>Thanks for the RFC. Some small =
remarks:</div><div><br></div><div><br></div><div>1. In =C2=A7 Add =
granular interfaces: `DimensionUnsetable` : I would have written =
=E2=80=9Cunsettable=E2=80=9D with 2 t=E2=80=99s (like =E2=80=9Csettable=E2=
=80=9D, =E2=80=9Cunforgettable=E2=80=9D, =E2=80=9Cregrettable=E2=80=9D, =
and like =E2=80=9Cunsetting=E2=80=9D).</div><div><br></div><div><br></div>=
<div>2. You propose to emit warnings in 8.4 for `$array[null]`, =
`$array[true]` and `$array[false]`. I argue that it should be =
deprecation notices instead. The reason is that currently no notice is =
emitted, and that there may be valid code that (implicitly or not) rely =
on the current behaviour. For =
example:</div><div><br></div><div>```php</div><div>function foo(?int =
$x): string {</div><div>&nbsp; &nbsp; static $cache =3D [ =
];</div><div>&nbsp; &nbsp; return $cache[$x] ??=3D =
heavyCalculationForFoo($x);</div><div>}</div><div>```</div><div><br></div>=
<div>and:</div><div><br></div><div>```php</div><div>$total_by_type =3D [ =
];</div><div>foreach ($list as $row) {</div><div>&nbsp; &nbsp; =
assert($row['type'] =3D=3D=3D null || is_string($row['type']) &amp;&amp; =
$row['type'] !=3D=3D '');</div><div>&nbsp; &nbsp; =
$total_by_type[$row['type']] ??=3D 0;</div><div>&nbsp; &nbsp; =
$total_by_type[$row['type']] +=3D =
$row['amount'];</div><div>}</div><div>```</div><div><br></div><div>The =
case of `$array[null]` is similar to `strlen(null)`, deprecated =
in:&nbsp;<a =
href=3D"https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg">ht=
tps://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg</a></div><div=
><br></div><div><br></div><div>3. Given the new semantics, =
`array_key_exists()` should be amended in order to support objects =
implementing =
`DimensionReadable`.</div><div><br></div><div><br></div><div>=E2=80=94Clau=
de</div><div><br></div><div><br></div><div><br></div><br></body></html>=

--Apple-Mail=_A1F85A9C-743B-454F-A4A6-C55991A7D651--