On Mon, 12 Jul 2021 at 02:09, Craig Francis <cr...@craigfrancis.co.uk> wrote: > > you can choose not to use string concatenation ... allowing anyone to > customise it to their needs
Please can you explain how: i) An individual programmer can enforce that they don't accidentally use string concatenation for stuff that is used in a security sensitive context. ii) A team of 50 programmers can enforce that they don't accidentally use string concatenation for stuff that is used in a security sensitive context. iii) A library can enforce that string concatenation isn't used in the params passed to it. > and doesn’t improve security in any way, It prevents issues from being able to make it through to production. But the main reason would be to reduce the cost of using this feature long-term. > you can choose not to use string concatenation (I haven't needed to). Wait....what? Is your position both that preserving literal-ness across string concatenation is required, otherwise this feature is too hard to use, and at the same time, you've not needed that in your own applications. Is that right? Because if preserving literal-ness across strings wasn't required for you...why would it be required for every other project? And to be clear, I don't think it's required. I think by listening to feedback from people who aren't sure it's a good idea, who said "this is a good idea but only if it's really easy to start using it" that this RFC has been watered down from the most useful proposal. At the core, there is a good idea behind this RFC, but the set of trade-offs chosen just aren't the right ones, and aren't the "proven" trade-offs made at Google. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
