Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CADKsZO1U-AL0_2WkOry6dh=oAeF_oRD-Z6G+93c9BqVffbL-_A@mail.gmail.com>
References: <CADKsZO1U-AL0_2WkOry6dh=oAeF_oRD-Z6G+93c9BqVffbL-_A@mail.gmail.com>
Date: Mon, 29 Aug 2016 08:17:50 -0600
Message-ID: <CAFMT4Nqg9WKDwerJ2rVcVvjPBdY+7eJa9NiBedwmqZA4E823aw@mail.gmail.com>
To: Igor Inas <igor.inas@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Nullable types before union types
From: levim@php.net (Levi Morrison)

On Mon, Aug 29, 2016 at 7:36 AM, Igor Inas <igor.inas@gmail.com> wrote:
> Hello,
>
> same as last post in the mailing list - this may have been suggested before
> - but I had hard time finding it in the archives.
>
> Coming from static typed languages, I love the addition of return type
> annotations and extension of parameter type annotations. I also love the
> fact, that types are not nullable by default.
>
> I am reading about the proposal to add nullable types before union types
> are fully implemented. This would be done by utilizing question mark (int?
> /  ?int).
>
> My question is: would it be too difficult to implement nullable types using
> syntax of union types, but semantically, only max two types would be
> allowed in the union and one of them would have to be null. So only allowed
> forms would be:
> - int | null
> - null | int
>
> I am thinking about the future, when union types become implemented and
> suddenly there would be two ways how to annotate the same nullable type:
> - int | null
> - int?
>
> Thanks for more insights,
> Regards,
> Igor

The union types RFC did not get enough support to pass. Additionally
having two forms of syntax to do the same thing is not the worst thing
that can happen in language design. They would at least be
semantically equivalent which is the important thing.