Hello, What about `is_vulnerable`? Its behaviour would be the inverse of is_literal. I mean we don't have to avoid the other side of the coin.
On Tue, 22 Jun 2021 at 22:41, Craig Francis <cr...@craigfrancis.co.uk> wrote: > Hi Internals, > > As the name `is_trusted()` seems to be causing contention, I think more > than the alternative option would. Since we want to get this right, and we > still have time before the feature freeze, this might be worth re-looking > at. Particularly if you are one of those unsure about it, read on. > > > > The name `is_trusted()` was chosen by a community vote over several days. > While I’m of a similar opinion that "trusted" might be misleading for some > in the strength of its word, I do not want to simply override 18 of the 21 > people, who I assume read the RFC, asked questions to clarify on the > mailing list, understood how it works, and have chosen that name. > > However, clearly some people missed the vote and its discussion time, and > some voted but then perhaps wanted clarifying on what the RFC was fully > about later. If we say that's about five people, then assuming there is a > larger audience who reads but does not post (as the voting numbers > indicated) then I'm inclined to guesstimate that maybe that means 3x the > number of people share those feelings. And with that number it starts to > feel like maybe we should double-check here. > > While a one-word name is always going to be misunderstood by some people, > we want to be as clear as possible. > > The Function: > - Is a security-based function that prevents Injection Vulnerabilities in > PHP. > - Flags strings written by the developer, including when concatenated. > - Also accepts integer values, which as purely numerical cannot contain > code/dangerous characters. (Due to technical limitations within PHP, it's > not possible for these to be flagged as user or developer in the codebase > itself without performance issues). > > (RFC for full breakdown: https://wiki.php.net/rfc/is_literal) > > Ideally we want a one-word name that suggests this as best we can - one > word to be consistent with other `is_*()` functions. > > - `is_literal()` was my original placeholder name. However, given that it's > not just literal strings, but also supports concatenation and integers I > felt it may be misleading with the definition of 'literal' stretched so far > it might get confusing, and is why I didn't include my original name for it > in the poll. However, if you feel it would be more accurate my mind isn't > fixed on it. > > - `is_known()` - suggested by Joe, who created the implementation, was one > of two options in the original vote, and was based on the principle that > the value be 'known' to the developer to be free from external code and be > within a 'known' understanding of the values that should be going in it. > > - `is_trusted()` - suggested by Moritz and separately by Mike, was the > second option in the original vote, and was based on the idea that what is > returned can be 'trusted' to be free from external code. > > I suggest that people who are serious in their feelings about this, offer > the name that they would prefer (including potentially making one > themselves that fits the RFC content and style mentioned above) so we can > assess whether the current name needs a second look. > > Thanks, > Craig >
