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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to