> On 22 Jun 2021, at 15:58, Stephen Reay <php-lists@koalephant.com> wrote:
>
>
>
>> On 22 Jun 2021, at 06:28, Craig Francis <craig@craigfrancis.co.uk <mailto:craig@craigfrancis.co.uk>> wrote:
>>
>> On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel <benjamin.morel@gmail.com <mailto:benjamin.morel@gmail.com> <mailto:benjamin.morel@gmail.com <mailto:benjamin.morel@gmail.com>>>
>> wrote:
>>
>>> On Tue, 22 Jun 2021 at 01:06, Derick Rethans <derick@php.net> wrote:
>>>
>>>> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>>>>
>>>>> The name "is_trusted" is misleading.
>>>>> Literal is nothing but literal.
>>>>
>>>> I agree with this. The name is_trusted is going to be the same naming
>>>> mistake as "safe mode" was. Developers will put their trust in it that it
>>>> is 100% guaranteed safe.
>>>
>>>
>>> FWIW, agreed, too. Trusted is vague and may imply some false sense of
>>> security. Literal is literally what it says on the tin.
>>>
>>
>>
>> I can follow up properly tomorrow, but by popular request we do support
>> integers as well (could be seen as stretching the definition of “literal” a
>> bit).
>>
>> And we did ask for suggestions last week, which ended up with a vote (as I
>> couldn’t decide).
>>
>> That said, I’m really glad that the only issue we seem to have is the name.
>>
>> Craig
>
> So I just want to make sure I understand the progression on this so far.
>
>
> It started out with people wanting a way to check that a string was a literal string, in code
> somewhere, and does not come from user input. Ok makes sense. The name makes sense too.
>
> Then someone said they wanted to check if an integer was a literal too - but because of
> technical limitations, it now allows any integer, regardless of where it came from, to be treated as
> a literal.
>
> Then because it’s not actually checking for literals, people thought the name “trusted”
> made more sense?
>
>
> That nobody thinks “any user supplied integer must be surely safe” is kind of hilarious,
> and sad at the same time.
>
> Knowing that a string is literal would be very helpful. Knowing that the string potentially
> still contains user input, in spite of the one thing it claims to do, is not just unhelpful, it
> makes the entire thing useless.
>
>
> I can’t vote, but this whole thing would be a No from me unless it was the original scope - a
> variable is a literal defined in code somewhere. If there are technical limitations with some types,
> then leave them off the list of what it will check.
s/nobody/anybody/
I blame a lack of caffeine.