> Am 02.06.2016 um 19:52 schrieb Fleshgrinder <p...@fleshgrinder.com>:
>
> On 6/2/2016 7:37 PM, Bob Weinand wrote:
>> Hey,
>>
>> I think this is more of a presentation problem.
>> As you say, there's not much a better way to do that.
>>
>> It's basically our weak casting rules, just applied to the most lossless
>> type available.
>> It's out weak casting rules which are so complex; the RFCs combination is
>> not particularly complex.
>> It needs to cover everything, but it's particularly important for the
>> trivial cases to be handled here. Would be quite WTF if you could not pass a
>> float to something accepting int (as one of its types).
>>
>> I'd welcome every suggestion to make the rules look less scary, because they
>> actually aren't.
>>
>> Bob
>>
>
> Don't you think this matrix would be a better presentation and simpler?
>
> |--------|--------|--------|--------|
> | type | #1 | #2 | #3 |
> |--------|--------|--------|--------|
> | bool | string | int | |
> | int | string | float | bool |
> | float | string | int | bool |
> | object | string | | |
> | string | float | int | bool |
> |--------|--------|--------|--------|
>
> Everything else is a TypeError.
Done that, does it look better now? :-)
> Note that I try string first all the time. Simply because it makes no
> difference for PHP afterwards, e.g.:
>
> function f(string|int $a) {
> if ($a == 1) echo 'foo';
> }
>
> f(true); // true ~> '1' ~> 1 = foo
>
> Even if the change I applied is not intelligent and is not a good idea
> (haven't thought about it deeply), the presentation as a table should
> help a lot.
There is one reason, it must not be inconsistent with strict types. Switching
from strict_types=1 to strict_types=0 shall always work without semantics
changes (as long as you don't catch TypeErrors).
> --
> Richard "Fleshgrinder" Fussenegger
Thanks,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
