Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83198
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Anthony Ferrara'" <ircmaxell@gmail.com>,
	<internals@lists.php.net>
References: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
In-Reply-To: <CAAyV7nGjdguX=4Nt0H=kYnwg8rZ1BkWf8duGZfzheOXXV61pqA@mail.gmail.com>
Date: Thu, 19 Feb 2015 16:13:54 +0100
Message-ID: <006401d04c56$ad1c5d00$07551700$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQNRCtsuxpDhJkWLwbpkER3sGaOi3Jn2iu/Q
Content-Language: de-ch
Subject: AW: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
From: php@tutteli.ch ("Robert Stoll")

Hey Anthony,

> -----Urspr=C3=BCngliche Nachricht-----
> Von: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Gesendet: Mittwoch, 18. Februar 2015 21:45
> An: internals@lists.php.net
> Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
>=20
> Dear Internals,
>=20
> Since the resignation of Andrea, the mixed-mode type hint (called =
declaration in the proposal) proposal has been left
> abandoned.
> Considering that the ending votes were 67/34 (66.3%) with several =
no-votes being only due to reasonably minor issues with
> the proposal, I would like to re-propose her RFC with three minor =
modifications:
>=20
> 1. declare(strict_types=3D1) (if used) is required to be the first =
instruction in the file only. No other usages allowed.
> 2. declare(strict_types=3D1) {} (block mode) is specifically =
disallowed.
> 3. int typed variables can resolve a parameter type of float So =
calling requiresAFloat(10) will work even in strict mode.
>=20
> As this topic has and is being discussed to death, I have put a very =
large "discussion points" section:
> https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
>=20
> I would kindly ask, before replying that you check to see if your =
question is answered in that list.
>=20
> If it is not, please follow up here and I will update the RFC.
>=20
> If your question is listed and you feel that it wasn't given proper =
due, please let's discuss that.
>=20
> https://wiki.php.net/rfc/scalar_type_hints_v5
>=20
> Considering this proposal is a minor tweak on an already-discussed and =
voted-on proposal, I plan on bringing this RFC to
> vote 1 week from today (on February 25th, 2015).
>=20
> Thanks,
>=20
> Anthony
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit: http://www.php.net/unsub.php

I have some questions:

you wrote: "aliases are removed (integer and boolean)"
what about the aliases real and double?

You wrote: "behaviour of weak type checks: float -> int *Only non-NaN =
floats between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see =
the ZPP Failure on Overflow RFC)"
What about INF? Can INF be passed or not and if so, how is it converted?

Personally I would be stricter and disallow int->bool, float->bool, =
string->bool as well as bool -> int, bool -> float and bool -> string =
(at least for this RFC)
Why?=20
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 affects extension and built-in PHP functions:" but control =
structures are not affected, right?)
2. It supports an inconsistency in PHP which we should try to get away =
with rather than promoting it. Following an example:

function foo(string $x){=20
  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 =
that 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 later on with consistent conversion rules. This way we have more =
time to think about a clean solution and adding implicit conversion from =
and to bool should also not be a BC break in 7.1

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.

Cheers,
Robert