Hey Anthony,

> -----Ursprüngliche Nachricht-----
> Von: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Gesendet: Mittwoch, 18. Februar 2015 21:45
> An: internals@lists.php.net
> Betreff: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
> 
> Dear Internals,
> 
> 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:
> 
> 1. declare(strict_types=1) (if used) is required to be the first instruction 
> in the file only. No other usages allowed.
> 2. declare(strict_types=1) {} (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.
> 
> 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
> 
> I would kindly ask, before replying that you check to see if your question is 
> answered in that list.
> 
> If it is not, please follow up here and I will update the RFC.
> 
> If your question is listed and you feel that it wasn't given proper due, 
> please let's discuss that.
> 
> https://wiki.php.net/rfc/scalar_type_hints_v5
> 
> 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).
> 
> Thanks,
> 
> Anthony
> 
> --
> 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? 
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){ 
  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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to