Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82140
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thekid.de from 212.227.126.130 cause and error)
Date: Sun, 8 Feb 2015 14:32:09 +0100 (CET)
Reply-To: Timm Friebe <php@thekid.de>
To: Internals <internals@lists.php.net>
Message-ID: <482375682.216572.1423402329172.JavaMail.open-xchange@oxbaltgw04.schlund.de>
In-Reply-To: <6C71C0BA-2B52-48D3-9AC9-41EEDD824EC5@ajf.me>
References: <162384795.216427.1423397046700.JavaMail.open-xchange@oxbaltgw01.schlund.de> <6C71C0BA-2B52-48D3-9AC9-41EEDD824EC5@ajf.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Medium
Subject: Re: [PHP-DEV] Reserving primitive types
From: php@thekid.de (Timm Friebe)

Hi,

> > I personally see the benefits this could have but also the BC break this
> > would
> > introduce.
[...]
> I don't see the point of this: the Scalar Type Hints RFC already has a voting
> option on reserving the type names, and it is set to pass, so by the time your
> RFC could go to a vote, it would have been rendered redundant.

My point is to prevent adoption hurdles *before* PHP 7's release. PHP 5 was a
sad story in regard to this. PHP 7 shouldn't be; and doesn't have to: So far,
PHP 7 has stayed largely BC-break free, which is good for its adoption. 

I believe more than just yes and no should be considered in this case, which
breaks existing code - not just in edge cases and in near-bug-scenarios. 

Timm