Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <006401d04c56$ad1c5d00$07551700$@tutteli.ch>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
	<006401d04c56$ad1c5d00$07551700$@tutteli.ch>
Date: Thu, 19 Feb 2015 17:58:36 -0500
Message-ID: <CAAyV7nF7dm5L=t+FfU1hupVynRxcOj6SRFdhZt4OO_rEPm3q=g@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
From: ircmaxell@gmail.com (Anthony Ferrara)

Robert,

> you wrote: "aliases are removed (integer and boolean)"
> what about the aliases real and double?

They were never part of Andrea's proposal. So they were never accepted anyw=
ay.

> You wrote: "behaviour of weak type checks: float -> int *Only non-NaN flo=
ats between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see the ZP=
P Failure on Overflow RFC)"
> What about INF? Can INF be passed or not and if so, how is it converted?

Please see the other RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow

Namely: The special floating-point values INF and -INF fail the check
like any other number that is too large.

> Personally I would be stricter and disallow int->bool, float->bool, strin=
g->bool as well as bool -> int, bool -> float and bool -> string (at least =
for this RFC)
> Why?
> 1. I already mentioned the common if(strpos(..)){} case but is something =
which none of the RFC addressed so far and probably goes too far (you wrote=
 "In addition to userland functions, the strict type checking mode also aff=
ects extension and built-in PHP functions:" but control structures are not =
affected, right?)

This only affects function calls. Not control structures.

> 2. It supports an inconsistency in PHP which we should try to get away wi=
th rather than promoting it. Following an example:
>
> function foo(string $x){
>   var_dump($x);
>   bar($x);
> }
> function bar(bool $x){
>   var_dump($x);
>   baz($x);
> }
> function baz(string $x){
>   var_dump($x);}
> foo(0);
>
> and the output would be:
>
> string(1) "0"
> bool(false)
> string(0) ""
>
> Sure, removing the implicit conversions from and to bool do not pretend t=
hat the same would happen if one uses manual conversions instead. Yet, IMO =
we should forbid the implicit conversion from and to bool now and add it la=
ter on with consistent conversion rules. This way we have more time to thin=
k about a clean solution and adding implicit conversion from and to bool sh=
ould also not be a BC break in 7.1

Simple: don't use weak mode. This proposal does not invent the weak
mode rules, it simply exposes them from ZPP (how it's implemented in
all internal functions) to userland hints.

So any change there would be outside of scope for this proposal and
should be made as another proposal. I will add this to the discussion
points section.

> Another example:
>
> function foo(int $x){
>   var_dump($x);
>   bar($x);
> }
> function bar(string $x){
>   var_dump($x);
> }
> foo(false);
> bar(false);
>
> and output:
>
> int(0)
> string(1) "0"
> string(0) ""
>
> I think you get the inconsistency I am writing about.
>
>
> About widening. It is not clear from the RFC if widening is only applied =
for int -> float or also for bool -> int, bool -> float respectively.

It's explicitly stated: "This means that parameters that declare float
can also accept int."

I will clarify this as well.

Thanks!

Anthony