Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111180
To: internals@lists.php.net
References: <CAF+90c82geReCwnejGM0Lg9UYyEoD6AyBYt+E7hj=x5aTmXK9w@mail.gmail.com>
Message-ID: <36d212ae-f5ef-9577-4077-ec43cfa8856d@gmail.com>
Date: Fri, 24 Jul 2020 20:31:42 +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: <CAF+90c82geReCwnejGM0Lg9UYyEoD6AyBYt+E7hj=x5aTmXK9w@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 23/07/2020 13:26, Nikita Popov wrote:
> PHP currently has an incorrect right-associative ternary operator. In
> https://wiki.php.net/rfc/ternary_associativity  the use of nested ternaries
> was deprecated, and was supposed to become an error in PHP 8.0.
>
> Concurrently with that proposal
> https://wiki.php.net/rfc/concatenation_precedence  made a very similar
> change to the concatenation operator precedence. The difference here is
> that this throws a deprecation notice in PHP 7.4 (same), but changes the
> behavior in PHP 8.0 (rather than making it an error).


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.

To give a real-life example, libraries that supported PHP 5.3 sometimes 
received patches containing the short array syntax introduced in 5.4. 
Since few projects have perfect test coverage and CI builds against 
multiple targets, these might end up in tagged releases. They were soon 
spotted by 5.3 users, because they caused a fatal error.

A similar mistake involving concatenation or ternary precedence (with 
code tested on 8.x and run on 7.x) would lead to much subtler bugs, and 
might go undetected for longer.

I realise that I am advocating an extra delay here, where I just argued 
the opposite regarding named parameters. I think the cost-benefit 
analysis comes out differently, notably on the benefit side:

- raising an error has significant benefits over the current behaviour, 
since it makes mistakes easier to spot
- the remaining benefit of the full change is only a mild convenience, 
since the behaviour can be achieved by adding parentheses

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]