Re: Re: [RFC] [PRE-VOTE] Union types

> Am 02.06.2016 um 19:52 schrieb Fleshgrinder <php@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