Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111185
To: PHP internals <internals@lists.php.net>
References: <CAF+90c82geReCwnejGM0Lg9UYyEoD6AyBYt+E7hj=x5aTmXK9w@mail.gmail.com>
 <36d212ae-f5ef-9577-4077-ec43cfa8856d@gmail.com>
 <CAK70goMWmsS7S2_u=KtmDw2N_Lo0aU79EKm-7yia49+0Sxd-rQ@mail.gmail.com>
Message-ID: <d154870a-84be-e51e-e90e-fda423bf7091@gmail.com>
Date: Sat, 25 Jul 2020 16:48:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAK70goMWmsS7S2_u=KtmDw2N_Lo0aU79EKm-7yia49+0Sxd-rQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Ternary associativity
From: rowan.collins@gmail.com (Rowan Tommins)

On 25/07/2020 16:26, Chuck Adams wrote:
> On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins <rowan.collins@gmail.com> wrote:
>
>> If anything, I would argue for making both of these into errors, if
>> that's possible. I think the biggest risk with this kind of change is
>> not existing code relying on the old behaviour, it is code relying on
>> the *new* behaviour which is accidentally run on older versions of PHP.
> I thought the proposal to turn unparenthesized use into a warning then
> waiting for PHP9 to use the proper precedence was the right idea.
> Nested ternaries with the proper precedence turn into lovely truth
> tables, which isn't even an uncommon idiom in C.  I'd really not like
> to feed /r/lolphp ammo by requiring the parens in all cases and
> continuing to break the ternary operator in comparison with every
> other language that has it.


I think we're talking at cross-purposes here; I'm not saying it should 
throw an error forever, I'm saying it should throw an error in PHP 8.x, 
and have new behaviour in 9.x, which as I understand it is the current 
plan.

Nikita is suggesting that it should instead change behaviour immediately 
in PHP 8.x, so that the below code would be valid in both PHP 7.4 and 
8.0, but with a different outcome:

$enableFoo =
    $config['foo']['enabled'] ? true
    : $config['foo']['disabled'] ? false
    : $config['default_enabled'] ? true
    : false;

I think there is too high a risk that a library would include that code 
intending the new behaviour, while claiming support for PHP 7.x, thus 
introducing a subtle and confusing bug.


The same risk applies to the concatenation case Nikita mentioned, which 
concerns code like this:

$priceLabel = $currencySymbol . $price + $tax;

Since PHP 7.4 detects the affected situations and raises an 
E_DEPRECATED, I think it would be safer to detect them and throw an 
error in PHP 8.x, rather than immediately changing behaviour.


In both cases, the correct behaviour can safely be added in PHP 9.0, 
since it's incredibly unlikely that code will be run on both 9.0 and 
7.x, but never on 8.x


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]