Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92293
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.215.46 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <alpine.DEB.2.20.1604141024070.3330@whisky.home.derickrethans.nl>
References: <CAFMT4NpJM_kaHLVuZ9OjghD7YkLi24jpBYnOZ=-43zb3-DNZPg@mail.gmail.com>
	<alpine.DEB.2.20.1604141008040.3330@whisky.home.derickrethans.nl>
	<CAKSD0w5WgK_boZpDKWatqkLBbNwpPqY7dLo7T-tuNfG1aK=NgA@mail.gmail.com>
	<alpine.DEB.2.20.1604141024070.3330@whisky.home.derickrethans.nl>
Date: Thu, 14 Apr 2016 03:18:28 -0700
Message-ID: <CANaX5ncuw3_Ff1RWYsMOrr6aQHnw=zKQDXTSy16dpqsJt1ryhg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Lin Yo-An <cornelius.howl@gmail.com>, Levi Morrison <morrison.levi@gmail.com>, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141153623c20e05306f3788
Subject: Re: [PHP-DEV] [RFC] Union Types
From: davey@php.net (Davey Shafik)

--001a1141153623c20e05306f3788
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As mentioned in my nullable types comment, I think that we should NOT add a
Null type unless the nullable types RFC fails to pass. We should not
introduce both options, and I favor the nullable types over this for that
purpose.

With regards to Dericks comment on type conversion, I think either simply
casting to the first type always, or we're going to have to come up with
some potential complex rules.

For example, what if you have: int|float, and pass in (string) "0.5", if
those were separate types you'd get (int) 1, or (float) 0.5 respectively,
and as a user I'd definitely expect it to be passed in as (float) 0.5 =E2=
=80=94
maybe we cast to the least lossy type? So if you have int|float, then a
numeric string always becomes a float.

The flip-side is that if we just decide first-always then it's up to the
developer to just define it as "float|int" instead.

I think Derick has definitely hit upon the trickiest part of this.

Also, just to clarify, if you combine this with the nullable types syntax
(assuming prefix), then the nullable applies to the entire union type:

?int|float =3D=3D=3D int | float | null

I do find the shorter syntax confusing TBH.

Which actually leads me to a different thought: defining custom types and
using them instead.

I very much like Hacks type/newtype stuff, if we extended that to support
union types:

newtype Numeric =3D int|float;

Then you end up with simply: ?Numeric as your type (it should be
namespaced).

You could further expand that with casting rules:

newtype Numeric =3D int|float {
      string as float;
      bool as int;
}

or even go so far as:

newtype Numeric =3D function($value): int|float {
     if ($value typeof int) {
         return $value;
     }

    return (float) $value;
}

FTR: I hate that last one, just spitballing.

- Davey

P.S.
if someone is willing to tackle the code for custom types I'm willing to
write an RFC

On Thu, Apr 14, 2016 at 2:25 AM, Derick Rethans <derick@php.net> wrote:

> On Thu, 14 Apr 2016, Lin Yo-An wrote:
>
> > On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans <derick@php.net> wrote:
> >
> > > I think what I am missing in the RFC is behaviour with scalar (weak)
> > > typehints, and which type the variable in a class would be converted
> to.
> > > Take for example:
> > >
> > > function foo(int|bool $var) { echo get_type( $var ), "\n"; }
> > >
> > > foo(5);     I guess int(5)
> > > foo(false); I guess bool(false)
> > > foo(0.5);   It could be either int(1) or bool(true)
> > >
> > > And what if the hint would be "bool|int" ?
> >
> > I think type conversion shouldn't be done internally, implicitly.
> >
> > Implicit conversion leads more confusion in the language. when you
> > pass variables, you have to remember these conversion rules.
>
> Sorry, we already have this with our weak scalar types. You can't make
> union types not work with that.
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--001a1141153623c20e05306f3788--