Re: [RFC] [VOTE] is_literal
| From: | Rowan Tommins | Date: | Mon, 12 Jul 2021 14:46:00 +0000 |
| Subject: | Re: [RFC] [VOTE] is_literal | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115408@lists.php.net to get a copy of this message | ||
On 11/07/2021 18:00, Dan Ackroyd wrote:
You've edited out the crucial last part of that sentence:What it won't do, is tell you when you've forgotten to use it,Which is a huge difference.
but nor would a built-in implementationI 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]