On Feb 8, 2015 10:52 AM, "Rasmus Lerdorf" <ras...@lerdorf.com> wrote:
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
> >> tan(1);
> >> echo strstr("test", "est", 1);
> >
> > Banning int->float and float->int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
discover if your ints floats would be silently truncated (as I did with
PictoSwap).
> >
> > I wouldn’t say that int->string not working is a problem, though.
Seeing something like strstr(“test”, “est”, 1); is rather confusing.
Looking at it, I’d think the third parameter is some sort of number for you
to want to pass an integer to it. If I want a string, I’ll use one.
>
> This isn't int->string. This is int->boolean. The 3rd arg to strstr() is
> a boolean and passing 1 instead of true makes it blow up. It is very
> very common for people to pass 0 or 1 in place of true/false to all
> sorts of things in PHP.
>
> > Yes, the RFC is somewhat inaccurate in that respect. It is per-file in
one sense (like encoding, but unlike ticks, it has no effect on the
including or included files). However, it technically affects the remainder
of the file, not the whole file.
>
> Well, no, not the remainder of the file either since it can be switched
> again. It only affects the part of the file between declares if there is
> a second one.For this specific weirdness it should really be fixed somehow, like for namespace. It has to be used at the top of a file. As it is a compile time thing, the extra check should not have much impact.
