Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com>
References: <9399032E-5BAA-4ABF-81AD-13716790D8DB@gmail.com>
Date: Fri, 25 Mar 2016 13:42:50 +0100
Message-ID: <CAF+90c8yhAfzTP7apPSbbrcSuqhiBv2Y_XAD=U5MLG+SoezFRA@mail.gmail.com>
To: Midori Kocak <mtkocak@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c07b516a930d4052edee6db
Subject: Re: [PHP-DEV] Combine ??= and ?:= assignment operator rfc's.
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c07b516a930d4052edee6db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 25, 2016 at 11:59 AM, Midori Kocak <mtkocak@gmail.com> wrote:

> Hi Everyone,
>
> 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.
>
> Wishes,
> Midori Kocak
>

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 vot=
e
was closed at something like 9:2, so there clearly are differences of
opinion regarding these two operators.

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 underspecifi=
ed
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?

The only statement the RFC essentially makes is that $a ??=3D $b will be th=
e
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.

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.

However, with ??=3D the problem becomes more complicated. Let us assume tha=
t
$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?

Let us now assume that $a is a recursive ArrayAccess object with
by-reference offsetGet() and consider the expression $a[0][1] ??=3D expr. F=
or
a normal compound assignment operator, this would issue the call sequence

    $b =3D expr;
    $x =3D& $a->offsetGet(0);
    $y =3D $x->offsetGet(1);
    $y OP=3D $b;
    $x->offsetSet(1, $y);

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 t=
he
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.

So, what would be the desugared call sequence for $a[0][1] ??=3D expr?
Something like this?

    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:

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.

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.

Regards,
Nikita

--94eb2c07b516a930d4052edee6db--