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
