Hi all,
PHP 7 has strict_types mode for function parameters/return values and
these are binded to certain type strictly.
https://wiki.php.net/rfc/scalar_type_hints_v5
Why not make strict_types mode more strict?
The idea is as follows:
<?php
declare(strict_types=1);
function foo(int &$i) {
$i = "string"; // Raise error
$i = function_returns_string(); // Raise error
$i = 1234.5678; // Raise error
$i = function_returns_float(); // Raise error
$n = 123;
// do something
$n = array(); // Raise error
}
?>
Assigning different type to already initialized variable is a bug most
likely. There may be cases that variable should have several types,
e.g. return INT for success and FALSE
for failure, but programmers can
use different variable or return value directly or make BOOL/NULL
exception.
This is useful with reference especially. For example,
<?php
declare(strict_types=1);
function foo(int &$i) {
$i = 'string';
}
$i = 0;
foo($i);
var_dump($i);
?>
outputs
string(6) "string"
Just an idea. Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Yasuo,
Le 17/09/2015 00:10, Yasuo Ohgaki a écrit :
Hi all,
Assigning different type to already initialized variable is a bug most
likely. There may be cases that variable should have several types,
e.g. return INT for success andFALSE
for failure, but programmers can
use different variable or return value directly or make BOOL/NULL
exception.
While I don't like the idea of 'auto-typing' a variable (assign it an
immutable type depending on the first assignment), the idea is quite
similar to one I proposed when we were discussing scalar type hinting :
the possibility to assign a type hint to every variable/property. In
order to be really usable, it requires compound types but that's a
detail because, anyway, we will need compound types.
The problem is that, AFAIK, it implies a mechanism to attach an optional
type hint to a zval, and check it each time a value is assigned. While
this would be extremely powerful and could dramatically change the way
PHP types are considered and handled, this is a huge and complex work,
especially in terms of performance. IMO, this may be an idea for 8.0,
not before. Anyway, I may be wrong, if you see a simpler way to
implement your concept, I'm interested.
Regards
François
The idea is as follows:
<?php
declare(strict_types=1);function foo(int &$i) {
$i = "string"; // Raise error
$i = function_returns_string(); // Raise error
$i = 1234.5678; // Raise error
$i = function_returns_float(); // Raise error
I think the problem here would be the same as with declaring types on object properties - it would require a major change to how the engine works so that every assignment operation had a potential for type checking, and strictness could stick to variables.
The reason the current type annotations can be enforced more easily is that they exist only on the boundary of a function, where variables are being copied into local parameters, and the function signature can readily hold the metadata.
There is also the question from the language design point of view of whether this is too "un-PHP-like". If you want something like PHP but with full type annotations, try Hack.
Regards,
Rowan Collins
[IMSoP]
Hi!
PHP 7 has strict_types mode for function parameters/return values and
these are binded to certain type strictly.
https://wiki.php.net/rfc/scalar_type_hints_v5Why not make strict_types mode more strict?
What you are proposing is not making strict_mode more strict, it is full
variable typing, and should be considered as such.
I personally do not think PHP needs that, but at least if it is
discussed then it should be discussed with proper understanding what it is.
--
Stas Malyshev
smalyshev@gmail.com
Yasuo Ohgaki wrote on 17.09.2015 00:10:
Hi all,
PHP 7 has strict_types mode for function parameters/return values and
these are binded to certain type strictly.
https://wiki.php.net/rfc/scalar_type_hints_v5Why not make strict_types mode more strict?
The idea is as follows:<?php
declare(strict_types=1);function foo(int &$i) {
$i = "string"; // Raise error
$i = function_returns_string(); // Raise error
$i = 1234.5678; // Raise error
$i = function_returns_float(); // Raise error$n = 123;
// do something
$n = array(); // Raise error
}
?>Assigning different type to already initialized variable is a bug most
likely. There may be cases that variable should have several types,
e.g. return INT for success andFALSE
for failure, but programmers can
use different variable or return value directly or make BOOL/NULL
exception.This is useful with reference especially. For example,
<?php
declare(strict_types=1);function foo(int &$i) {
$i = 'string';
}$i = 0;
foo($i);
var_dump($i);
?>outputs
string(6) "string"
Just an idea. Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hey,
I think there is a lot of code out there that changes types, but is not a bug, e.g.:
$params = array('a', 'b');
$params = json_encode($params);
So I would extend the declare parameters:
declare(strict_types=1, strict_declare=1);
function foo(int &$i) {
$i = "string"; // Raise error
...
Regards
Thomas
Yasuo,
Hi all,
PHP 7 has strict_types mode for function parameters/return values and
these are binded to certain type strictly.
https://wiki.php.net/rfc/scalar_type_hints_v5Why not make strict_types mode more strict?
The idea is as follows:<?php
declare(strict_types=1);function foo(int &$i) {
$i = "string"; // Raise error
$i = function_returns_string(); // Raise error
$i = 1234.5678; // Raise error
$i = function_returns_float(); // Raise error$n = 123;
// do something
$n = array(); // Raise error
}
?>Assigning different type to already initialized variable is a bug most
likely. There may be cases that variable should have several types,
e.g. return INT for success andFALSE
for failure, but programmers can
use different variable or return value directly or make BOOL/NULL
exception.This is useful with reference especially. For example,
<?php
declare(strict_types=1);function foo(int &$i) {
$i = 'string';
}$i = 0;
foo($i);
var_dump($i);
?>outputs
string(6) "string"
Just an idea. Any comments?
First, as mentioned by others, this really doesn't have overly much to
do with strict_types. It's introducing a new concept (which could
potentially be a new declare statement).
Second, i think the biggest limitation here is technological. If you
can find a way internally to type variables properly while keeping
copy-on-write semantics, then we can start that conversation on
whether we really want to do that or not. But so far, everyone I've
seen try to do something like that (namely for typed properties) has
wound up causing all sorts of weird edge-cases around references or
copy-on-write. Which is one reason we haven't seen a full proposal yet
for it.
So if you can come up with a patch that works, let's definitely talk
about it. But as Stas said, it's really not just making types more
strict, but it's fully blown variable typing. Which we can talk about,
but let's talk about explicitly (and preferably with an implementation
approach).
Thanks!!!
Anthony