[RFC] Union Types

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 —
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 === 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 = 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 = int|float {
string as float;
bool as int;
}

or even go so far as:

newtype Numeric = 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

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

Derick Rethans derick@php.net 於 2016年4月14日 星期四寫道：

On Thu, Apr 14, 2016 at 5:12 PM, Derick Rethans <derick@php.net
javascript:;> wrote:
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.

Does Hack support weak type conversion?

--
Sent from Gmail Mobile

I think it will be better if union type is only allowed in the "type"
statement, like what you described in your RFC.

type Iterable = Array http://www.php.net/array | Traversable;

If we can always pre-define the types.

And only allow just one type for each function parameter in the function
prototype, then, I think the performance impact of type checking in the
runtime might be able to be reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.