Am 26.12.2017 um 19:18 schrieb Larry Garfield:
On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote:
Am 26.12.2017 um 16:46 schrieb li...@rhsoft.net:
would you mind to explain this?
"Foo|Bar", "array|string", etc. (still) make no sense to me.
"scalar" makes sense to me although it is but an alias for
"bool|float|int|string".
If I may, I think the argument has always been that
1) Foo & Bar makes total sense
2) int|float makes total sense
3) int & string is illogical so wouldn't matter anyway
not true
function x(int|string $x)
{
$x = (int)$x;
}
$x can be simply from a database simply because without
MYSQLI_OPT_INT_AND_FLOAT_NATIVE which is sadly not default you get
everything back as string and so you can place the casting in the
function instead of every single caller in strict_types mode while you
don#t accept object, array or boolean here
why not cast a boolean here?
in case of the result of strpos() in the caller is false it likely
should not call the function anyways but handle that error itself
4) Foo|Bar rarely makes sense but may sometimes, and its legality is an
acceptable trade-off to get the first two.
In previous discussions it always seemed that people fixated on case 4 and
ignored the usefulness of cases 1 and 2
as this is a programming language it's up to the user who writes the
code in the language what is useful for his case - so if one is fixated
on 3 or 4 because they would become possible the argumentation is
strange anyways and "etc. (still) make no sense to me" is a personal
opinion which hardly justifies a downvote at all unless there are real
technical reasons
in my total valid usecase of 3) above in strict_types mode i must ommit
the typehint at all or modify every single caller and that alone would
justify unions
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
