2015-02-21 1:07 GMT+01:00 Pádraic Brady <padraic.br...@gmail.com>:
> On 20 February 2015 at 23:38, Larry Garfield <la...@garfieldtech.com>
wrote:
>> While I love the idea, strict type comparison for in would, in essence,
be a
>> toe-dip into the scalar strict typing world (see other thread) that
would be
>> very confusing. Consider:
>>
>> if (3 in $_GET['filters']) { ... }
>>
>> That would always be false, because $_GET is always strings. To make
that
>> work I'd need to first cast all of the elements in that array to ints...
>> which I'm not actually sure how to do cleanly.
>
> You need casting anyway if comparing raw GET/POST directly to any
> integer as a decision point on whether to use the raw value, i.e. it's
> unvalidated otherwise and could have been "1234<script>[...]".
>
> Yes, I'm abusing your intentionally very simple example. There are
> other cases away from user input where looser comparisons wouldn't
> have the same potential issues with non-permanent type juggling. I
> would be a huge fan of having it be strict since the above, while
> clearly a simple example, has been problematic in the past for
> validation routines and, as a security guy, I'm obsessed with that ;).
> Also, on toe-dipping into strict typing, I think your opinion may be
> slightly overweight towards that topic given recent RFC history - we
> already have === as our toe in the water.
>
>> I'd much rather we tighten up the rules around implicit casts generally,
as
>> discussed elsewhere, and then allow those "loose but not as loose as we
have
>> now" rules here.
>
> I could work with that perhaps. RFCs of this type are in a bit of a
> bind while we wait for scalar typehints/potential casting rules to be
> finalized in some form. It also appears unlikely that "in" as the
> operator name will pass muster if the context sensitive lexer RFC does
> not pass, i.e. would break uses of in() as a method name.
>
> Niklas, any chance you have considered a Plan B for the operator
> naming? Mostly curious if these is already some alternative outside of
> the field of langs I'm familiar with that might be acceptable.
>
> Paddy
>
> --
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
if (3 in $_GET['filters']) { ... }
> That would always be false, because $_GET is always strings. To make that
> work I'd need to first cast all of the elements in that array to ints...
> which I'm not actually sure how to do cleanly.
You could easily cast the left operand to a string instead.
I'd much rather we tighten up the rules around implicit casts generally, as
> discussed elsewhere, and then allow those "loose but not as loose as we
> have now" rules here.
Maybe I'd be OK with that then, but not in the state we currently have. I
think a change here would be too rushed and would therefore have to wait
until PHP 8.
> Niklas, any chance you have considered a Plan B for the operator
> naming? Mostly curious if these is already some alternative outside of
> the field of langs I'm familiar with that might be acceptable.
Not really. It could be named `contains`, but that would create the same
problems.
It also appears unlikely that "in" as the
> operator name will pass muster if the context sensitive lexer RFC does
> not pass, i.e. would break uses of in() as a method name.
You're totally right. It's already the second RFC on that topic (
https://wiki.php.net/rfc/keywords_as_identifiers is the other one I know).
If context sensitive lexer doesn't parse, "in" may have to wait until PHP
8, which may have another RFC here.
Regards, Niklas
