On 16/07/2014 23:12, Andrea Faulds wrote:
Of course, we could just make it a glorified E_NOTICE, but then what’s the
point? E_NOTICE already exists.
I just realised something that's made me really confused about this
whole debate: internal functions already emit E_NOTICE for *exactly* the
case we're discussing!
Maybe this was obvious to the rest of you, but this:
date('d', '123abc');
gives this:
Notice: A non well formed numeric value encountered
So, we already have a notion of what casts are "well formed" and what
aren't! Clearly, I've been running with notices suppressed for too long,
or I'd have realised this sooner, and I think I've been talking at
cross-purposes with Zeev and others because nobody had directly
mentioned this.
Now, I have no idea how ZPP actually works, and get lost in a maze of
macros whenever I try to look at it, but evidently it has logic to
distinguish, at least for string->int, three cases:
1) safe / lossless / well formed input (cast silently), e.g. '123' =>
int(123)
2) unsafe / lossy / non well formed (give a notice), 'e.g. '123abc' =>
int(123)
3) impossible / inappropriate (from the point of view of the user, give
a warning, and cause different behaviour of the function), e.g. 'abc' => int
Note that this is completely different from implicit casts, which have
also been mentioned a lot, since those perform no validation at all
(e.g. 'abc' + 'def' will happily give you int(0)). [Or that's what I
think of when someone says "implicit cast", anyway; I think it's what
the manual calls "type juggling".]
So what are we actually talking about with Andrea's (/ Anthony's)
current RFC / patch?
Firstly, as I understand it, the current proposal treats both category 2
and 3 as errors, in the context of userland typehints. Is there a
compromise possible where only category 3 is treated as an error, and 2
as a warning? Or some other position which keeps them distinct, but
detects both, as internal functions appear to do?
Secondly, there is mention of cases where the categorisation differs.
I'm not really clear what those actually are.
So, my apologies for being slow on the uptake, but given the mix of
people extremely familiar with the core, and people familiar only with
its effects on userland, I wonder if I'm not the only one.
Humble regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
