Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115408
To: PHP internals <internals@lists.php.net>
References: <CAFv4g+HRHrvCOTgpbVfCXj06De1kL+1+RwnGgq6tcyLNAtLfQA@mail.gmail.com>
 <CAFPFaMJs7qvko=tfBsXuwCqMV3VqXL4TjO2aKWWPjrAicZzM9w@mail.gmail.com>
 <782e08f6-d6a1-e1e7-b2d6-4706277a4d86@gmail.com>
 <CA+kxMuSuqaPq_q8eZy2_pHQNr1zMNjout2f2bZc=ZUZiBx3mPQ@mail.gmail.com>
Message-ID: <d5836dbc-a534-ef46-6377-2b4569a3b646@gmail.com>
Date: Mon, 12 Jul 2021 15:46:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CA+kxMuSuqaPq_q8eZy2_pHQNr1zMNjout2f2bZc=ZUZiBx3mPQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] [VOTE] is_literal
From: rowan.collins@gmail.com (Rowan Tommins)

On 11/07/2021 18:00, Dan Ackroyd wrote:
>> What it won't do, is tell you when you've forgotten to use it,
> Which is a huge difference.


You've edited out the crucial last part of that sentence:

 > but nor would a built-in implementation


I don't know how to make this point more emphatically: Neither a 
built-in literal_concat function, nor setting the internal flag to false 
when you use the "." operator, can prevent you using plain concatenation 
in the wrong place.


Regardless of what the . operator does to the internal literal flag, the 
following code will give an error in exactly the same place:

// What this line does to the literal flag is irrelevant:
$blah = 'a' . 'b';
// This line will set the literal flag to false, but will not raise any 
errors:
$foo = $blah . $_GET['foo'];
// $foo is not literal, so $bar is not literal; but there are still no 
errors:
$bar = $foo . '123';
// Finally, an error will be raised when trying to use $bar in 
literal_concat, regardless of whether it's built-in or user-implemented:
$baz = literal_concat($bar, '456');


The only way to put that error in a different place would be if the . 
operator itself was able to raise errors, and I can't think of any way 
that would be possible.

Regards,

-- 
Rowan Tommins
[IMSoP]