> -----Original Message----- > From: Andrea Faulds [mailto:a...@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 <smalys...@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’t 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 not 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
