I'll take this opportunity to say thank you, for this, and all the other hard work you put into PHP internals.
I still think adding a string to a number should error instead of giving a warning, but one thing at a time. PHP7 and the future roadmap makes it look like PHP is on a path to not turning into Perl.
* Numeric and string operators are kept distinct. For example `+` means numeric addition, never concatenation or some other string operation. To compare two strings, use `eq`, to compare two numbers use `==`. Etc. This sets things up nicely for supporting both DWIM and DWIS typing.
* DWIM typing: If you write something like `a + b`, you always get numeric addition. If need be the compiler tries to coerce `a` and `b` to numbers. `"12"` or `" 12" will both successfully coerce to 12. `"123foo"` and `"bar456"` will fail to coerce. If the coercion fails the program crashes at run-time.
* DWIS typing: To tighten type checking, add a type constraint. For example, `my Numeric (\a, \b) = ...` ensures that `a` and `b` only ever contain a numeric value.
Also, it helps prevent the abuse of interfaces. I can say "this method does not return values" and enforce it. That can be useful on a big project, with junior devs.
PHP's built-in functions documented as "void" also return NULL, so I suppose there's an argument from consistency.
> Choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. https://wiki.php.net/rfc/void_return_type#why_isn_t_return_n...
I guess this 'pragmatism over consistency' fits in with the general ethos of PHP. I guess it's why so many people hate it, but I can't imagine a situation in which this will actually cause a problem.
There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.
https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...
... has an obvious code smell detectable statically:
https://github.com/facebook/hhvm/blob/HHVM-3.13/hphp/hack/te...
Maybe you can answer this for me.
Will this work:
$f = [$c, $d] = [1, 2];
$f = list($c, $d) = [1, 2];
$c = 2;
$d = 3;
$f = [$c, $d] = [1, 2];
Plus:
$f = $c = $d;
$c = 2; # Assign 2 to $c
$d = 3; # Assign 3 to $d
[$c, $d] = [1, 2]; # Assign 1 to $c, assign 2 to $d
$f = [$c, $d]; # Assign [1, 2] to $f class Person
{
public $name : string;
public $age : int;
public $isEmployee : bool;
} public function __construct(string $name, int $age, bool $isEmployee);
Hack doesn't do this either.
I do think the idea came up.
Thank you for getting these added to the language, I think it's a fantastic improvement.
Though the details may differ significantly. Hack and PHP's type systems are only superficially the same (AOT rather than runtime validation, disabling or ignoring type checks versus using "weak" type checks, type inference vs. no type inference, etc.), for example.
In a less facetious spirit, it's interesting to see languages converge a lot. Darwinian gene dynamics.
Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat.
First, it's now possible to declare nullable return types (previously all return types did not permit null):
(You can also use ? on parameter and property types.)Second, we now have a void return type for functions where there is no useful return value:
(Disclaimer: I wrote the void return type RFC and implementation, so I'm biased here.)We're also getting type declarations for class properties:
There's a few other things as well. The list() syntax (destructuring assignment) has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these). Also, trying to add non-numeric strings together with + now produces a warning (disclaimer: also me).