Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99135
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
Date: Tue, 23 May 2017 16:50:09 -0600
Message-ID: <CAFMT4NoF3PDMa2AKGbuoYErS1Li0RxVm=A0k4JKj9VyVPjwk4Q@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11409d844fcce3055038cf3a"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: levim@php.net (Levi Morrison)

--001a11409d844fcce3055038cf3a
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 1:25 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
>

This was my opinion at voting time which is why i voted against the RFC. It
passed 24 to 5 so it's just something we'll have to live with for now.

--001a11409d844fcce3055038cf3a--