Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78253
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.174 as permitted sender)
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <CA+9eiLs9j0XMbtNKSSuqTBhF-BEc1CU__3E4gOhYwuF5zF4_1g@mail.gmail.com>
 <866A39C7-6F11-408D-8BCA-594BA22E8569@ajf.me> <CA+9eiLutEFyZsJGu9Qk9C7Jd0P48SBXcdRiVyySbqXbEYm3Y3w@mail.gmail.com>
 <5447682B.2080100@sugarcrm.com> <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me>
In-Reply-To: <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJkwG276Wk0Upx97kt7WiAQcULrfAGSwBqnAi5QI8QCGl+NrgJ4wNJWAjMdez6avspE8A==
Date: Thu, 23 Oct 2014 01:01:41 +0300
Message-ID: <77c09d71b5ee91245640e414c320518d@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Wednesday, October 22, 2014 9:20 PM
> To: Stas Malyshev; Zeev Suraski
> Cc: Dmitry Stogov; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
>
>
> > On 22 Oct 2014, at 09:17, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> >
> > If those are opcodes, those rules will require 2/3 majority for
> > acceptance, since those will be the engine rules for type conversion,
> > not just a set of functions. And, of course, the rules not matching
> > the other engine rules for type conversion, sorry for sounding like
> > broken record.
>
> No, it wouldn=E2=80=99t require a 2/3 majority.

Andrea,

It absolutely would, regardless of the optimization.  Whether or not it's
implemented as functions or opcodes indeed matters very little.  What
matters is what it will be perceived as by average developer.  And a set of
functions named to_int() will absolutely be perceived as a part of the core
language, in the same way is_int() is.

The RFC itself makes an assertion that fundamentally contradicts the notion
that these are 'just functions'.  The RFC reads 'They also prevent any
suggestion of strict type hinting for scalar types, because if that were to
be added, users would simply use dangerous explicit casts to get around
errors and the result would be code that is buggier than it would have been
without type hinting at all.'  While it doesn't explicitly say so, it's
clear that one of the goals of the RFC is make it easier for a 'strict
typing' RFC to be accepted in the future.  This is a clear indication this
constitutes a fundamental change to the core language.

Changing the function names so that will diffuse confusion on whether or no=
t
they represent the official typing rules of PHP - can change this into a
50%+1 RFC.  Otherwise, this is a very, very clear 2/3 RFC.

Zeev