Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92077
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <5700FB39.2030303@telia.com>
Date: Sun, 3 Apr 2016 16:41:36 +0200
Cc: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <ABD5C8BE-55E9-4F3A-8957-C076AFE8C3D0@gmail.com>
References: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com> <CAF+90c8yhAfzTP7apPSbbrcSuqhiBv2Y_XAD=U5MLG+SoezFRA@mail.gmail.com> <63C58928-255D-41A1-9D6E-4773CF9DB356@gmail.com> <5700FB39.2030303@telia.com>
To: =?utf-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Subject: Re: [PHP-DEV] Tests for null coalescing assignment operator
From: mtkocak@gmail.com (Midori Kocak)

Yes, I think I should too. But still no feedbacks :(

> On 03 Apr 2016, at 13:15, Bj=C3=B6rn Larsson =
<bjorn.x.larsson@telia.com> wrote:
>=20
> Hi Midori,
>=20
> Will you update the RFC also? Even if it's not the normal way of doing
> things, one should keep in mind that RFC's are often listed as =
references
> in books about PHP, being the first piece of documentation. Two such
> examples are:
> - https://daveyshafik.com/archives/book/upgrading-to-php-7
>  # In Appendix B
> - http://www.php7book.com
>  # At the end of every chapter
>=20
> Regards //Bj=C3=B6rn Larsson
>=20
> PS Maybe best to finish implementation and tests first.
>=20
> Den 2016-04-03 kl. 03:17, skrev Midori Kocak:
>> Dear All,
>>=20
>> Based on the concerns I wrote some tests. Can you check those and =
give feedback? Also, in ruby, $a ||=3D $b, the implementation is not =
equal to $a =3D $a || $b, but is equal to $a || $a =3D $b; I am a little =
bit confused, I am not entirely sure, but I guess this approach would =
solve our problems.
>>=20
>> https://gist.github.com/midorikocak/abc9fd9b6ca30359d201bc859edba9ee =
<https://gist.github.com/midorikocak/abc9fd9b6ca30359d201bc859edba9ee>
>>=20
>> We can use these examples as the part of the new documentation and as =
a guideline for implementation tests. Can you add also any extreme cases =
that should raise errors to my test?
>>=20
>> Yours,
>> Midori
>>=20
>>> On 25 Mar 2016, at 13:42, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>>=20
>>> On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtkocak@gmail.com =
<mailto:mtkocak@gmail.com>> wrote:
>>> Hi Everyone,
>>>=20
>>> I think it's better idea to combine those two assignment operator =
RFC=E2=80=99s. So I am going to close the current one and open ??=3D =
with ?:=3D
>>> What do you think? And we have to find better names.
>>>=20
>>> Wishes,
>>> Midori Kocak
>>>=20
>>> I'd prefer to keep them separate, or at least keep their votes =
separate. The ??=3D operator vote is currently unanimous at 24:0, while =
the ?:=3D vote was closed at something like 9:2, so there clearly are =
differences of opinion regarding these two operators.
>>>=20
>>> I'll use this chance for some comments on the proposal. I can see =
the general usefulness of ??=3D, but right now the RFC is severely =
underspecified and I'm uncomfortable voting on it in it's current form =
as so much will depend on the final implementation. So, what do I mean =
by underspecified?
>>>=20
>>> The only statement the RFC essentially makes is that $a ??=3D $b =
will be the same as $a =3D $a ?? $b, for variable-expression $a and =
expression $b. This statement, while a good high-level illustration, =
does not explain the exact behavior of this operator.
>>>=20
>>> For example, consider the expression $a[print 'X'] ??=3D $b. A =
simple desugaring into $a[print 'X'] =3D $a[print 'X'] ?? $b will result =
in 'X' being printed twice. However, this is not how all other existing =
compound assignment operators behave: They will print X only once, as =
the LHS is only evaluated once. I assume that ??=3D would behave the =
same way.
>>>=20
>>> However, with ??=3D the problem becomes more complicated. Let us =
assume that $a is an ArrayAccess object and consider the expression =
$a[0] ??=3D $b. Let us further assume that $x =3D $a->offsetGet(0) is =
non-null. Will $a[0] ??=3D $b result in a call to $a->offsetSet(0, $x)? =
This is what would normally happen with a compound assignment operator =
and what would be implied by the desugaring $a[0] =3D $a[0] ?? $b. =
However this assignment is not really necessary, as we're just =
reassigning the same value. So, does the call happen or not? Is the =
proper desugaring maybe if (!isset($a[0])) $a[0] =3D $b?
>>>=20
>>> Let us now assume that $a is a recursive ArrayAccess object with =
by-reference offsetGet() and consider the expression $a[0][1] ??=3D =
expr. For a normal compound assignment operator, this would issue the =
call sequence
>>>=20
>>>     $b =3D expr;
>>>     $x =3D& $a->offsetGet(0);
>>>     $y =3D $x->offsetGet(1);
>>>     $y OP=3D $b;
>>>     $x->offsetSet(1, $y);
>>>=20
>>> Note that we only issue one offsetSet() at the end. We do not =
refetch $x via $a->offsetGet(0). How would the same work with the ??=3D =
operator? As the RHS is evaluated lazily, it is my opinion that only =
performing the offsetSet() call without refetching $x beforehand would =
violate PHP's indirection memory model. Additionally as ??=3D has to =
fetch offsets in BP_VAR_IS mode, we likely wouldn't be able to write =
them without refetching anymore.
>>>=20
>>> So, what would be the desugared call sequence for $a[0][1] ??=3D =
expr? Something like this?
>>>=20
>>>     if (!$a->offsetHas(0)) {
>>>         goto assign;
>>>     }
>>>     $x =3D $a->offsetGet(0);
>>>     if (x =3D=3D=3D null) {
>>>         goto assign;
>>>     }
>>>     if (!$x->offsetHas(0)) {
>>>         goto assign;
>>>     }
>>>     $y =3D $x->offsetGet(0);
>>>     if ($y =3D=3D=3D null) {
>>>         goto assign;
>>>     }
>>>     goto done;
>>> assign:
>>>     $b =3D expr;
>>>     $x =3D& $a->offsetGet(0);
>>>     $x->offsetSet(1, $b);
>>> done:
>>>=20
>>> That would be some first thoughts on the issue, though I'm sure =
there are more subtleties involved. I'd like to see the exact behavior =
of ??=3D (and ?:=3D) specified.
>>>=20
>>> I'm also pretty sure that writing a patch for this will not be =
entirely easy. The combination of execute-once LHS side-effects and lazy =
RHS execution does not translate well to PHP's VM constraints.
>>>=20
>>> Regards,
>>> Nikita
>>=20
>=20