On Fri, Dec 29, 2017 at 1:08 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> 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`).
>
int|float is the natural type of numeric operations in PHP. Integers
automatically overflow into floating point numbers, so signatures using int
in conjunction with numeric operations are somewhat problematic.
Having an explicit number type also goes well with an explicit number cast.
PHP internally has a notion of a number cast (which is the basis for
arithmetic operations), but currently does not expose it. As such, number
casts currently have to be simulated using workarounds like +$x.
Regarding the union type RFCs, from what I remember, one of my personal
issues with it were the complex rules involving scalar type unions in weak
typing mode. It's non-trivial to decide what a value should be casted to if
it does not have the correct type. It's sort of clear what "1.5" passed to
an int|float union becomes, but it's not intuitively obvious what should
happen if you pass "foo" to a bool|int union, etc.
Regards,
Nikita
