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
