On 12/29/2017 12:21 AM, Larry Garfield wrote:
> On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote:
>> On 26 December 2017 18:35:29 GMT+00:00, "li...@rhsoft.net"
> <li...@rhsoft.net> wrote:
>>> Am 26.12.2017 um 19:18 schrieb Larry Garfield:
>>>> 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;
>>>
>>> }
>>
>> I think there's a misunderstanding here. Some previous proposals for "union
>> types" also included "intersection types", so that you could assert
>> "parameter must implement both of these interfaces". So 'Foo|Bar $x' would
>> mean '$x instanceof Foo || $x instanceof Bar' and 'Foo&Bar $x' would mean
>> '$x instanceof Foo && $x instanceof Bar'.
>>
>> I presume that's what Larry means by "int & string is illogical", because it
>> would translate to "is_int($x) && is_string($x)", which is false for all
>> values of $x. This is different from "int | string", which, as you say,
>> might have valid uses.
>>
>> Regards,
>
> Correct. Union types I've always seen presented as offering both union and
> intersection. There are cases where union is great, and where it's kinda
> silly. There are cases where intersect is great, and where it's kinda silly.
>
> Most of the anti- arguments I've seen for "union types" have fixated on "int
> &&
> string is meaningless, and Foo || Bar is bad design, so union types are bad!"
>
> Entirely ignoring the flip side, which is int || string (valid use cases) and
> Foo && Bar (many many valid use cases).
>
> --Larry Garfield
>
What is the use case for `int|float`? I mean, if f is able to process a
`float` than f is able to process an `int` and since `int` is already
automatically changed to a `float`, well, you're done.
The only situation (I can think of) where this might make a difference
is while formatting them. However, in those cases one usually wants to
accept many more types (or better yet, let the type format itself).
I think that the union RFC was missing proper rules for disjunction (and
conjunction if intersection were to be included) as well as information
on disjointness. The latter would be important for exhaustive switches
that are enforced by the runtime (we'd probably need new keywords here,
e.g. `match` + `is`).
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
