> 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
This issue is addressed partially in the future scope section of the
RFC: https://wiki.php.net/rfc/union_types#long_type_expressions.
If both nullable and full union types are allowed I was planning on
disallowing the short-hand notation when using unions. As it isn't
that relevant at this stage it isn't noted in the RFCs anywhere.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
