Re: [VOTE][RFC] Scalar Type Hinting with Cast

> On 14 Sep 2014, at 07:32, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > > Calling this "scalar type hinting with cast" when it doesn't actually > cast in wide variety of cases sounds a bit misleading to me. It should > be called "scalar type checking with restricted casting" or something > like that. I'd agree it's not the best name. This is mainly a decision to make when this is documented or added to the language spec. If we change this thing's name, we should perhaps stop calling typed parameters 'type hints'. > I would also ask to clean up an RFC a bit and to clarify which of the > proposed choices and "possible changes" are actually being voted for > when somebody votes "yes". The vote would be for the RFC as it is. Possible changes are things in the RFC I was uncertain on. I might hold votes on some of them, actually. > In any case, I call everybody to vote against this RFC in this form, > since it introduces inconsistency between internal and user functions > and makes PHP have two different arbitrary sets of rules for implicit > conversions, and this can not be good for PHP. I had abandoned the RFC for this reason. However I gave up trying to improve zpp and make it consistent with user land hints, or adding user land hints which match zpp. The problem is that we *can't* be consistent. Internal functions already live in this completely different world from user land functions. Nullability is handled differently. They use implicit casts in places as if they were user land functions with no parameter types at all. In other places they have strongly typed parameters. If they are passed invalid data, they usually just return NULL and emit a warning, though this depends on the function. User land functions, by contrast, will emit a recoverable error if the wrong type is passed. To make these two consistent would require massive backwards-compatibility breaks. If we're just talking about casting, then this proposal does not alter casting behaviour, in fact I've been very careful not to touch it. It does, however, only accept a subset of the values zpp usually does. This is because it is a compromise between strict and weak parameter typing. While I understand you might like it to be fully weak like zpp, many userland developers are in favour of something stricter, thus the compromise. Unlike zpp's rules, at least these rules are clearly specified and prevent data loss. Thanks! -- Andrea Faulds http://ajf.me/