Re: Reviving scalar type hints

In a word, yes. Have to say you're abilities to compile Zeev -> formal declaration are pretty amazing :) Zeev > On 17 בפבר׳ 2015, at 08:20, Sara Golemon <pollita@php.net> wrote: > >> On Mon, Feb 16, 2015 at 10:04 PM, Zeev Suraski <zeev@zend.com> wrote: >> That syntax poll aside, I had what I hope is some sort an enlightenment, and >> I think I know what will get me to cast my vote in favor of 'strict', as a >> true supporter. There's one very special conversion that's too common in >> PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the >> cases, if not strictly 100%: >> >> string->int or string->float conversions, when the string looks *exactly* >> like a number. Given almost all of our inputs (from databases, forms, >> files, etc.) come in string form, that's by far the conversion that's going >> to give us the most trouble - and is most probably the use case that by far >> is going to result the largest amount of explicit casts to work around that >> problem. >> >> What if strict mode didn't just blindly check zval.type, but actually >> allowed for this one type of conversion to go through without a problem? >> >> No bool to int. No Apple to int. No "123 testing" to float. Just >> "32" to >> 32 and "37.7" to 37.7. >> >> Can the strict supporting camp consider that option? Judging by the >> examples brought up by proponents of v0.3, this type of conversion isn't >> their issue. It's the 'obviously wrong' conversions that bug them. >> >> As a secondary concern I'd put int to float conversions where no >> (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of >> accuracy is lost. Rejecting this particular conversion places us at being >> stricter than mostly all other languages. That said, it's a much less >> common conversion so I don't feel nearly as strongly about it as the string >> one. >> >> Last, regarding internal functions, I do agree with Rasmus and Drew. Again, >> judging by the examples brought up as a part of the discussion, it seems as >> if we gave ZPP developers a standard easy way of being a lot more picky >> about the types of values of particular arguments, and allowing them to do >> this selectively for those places that are very sensitive (e.g. >> curl_setopt()) would be a more suitable solution than just turning strict >> validation for all internal functions, which were built with very very >> different assumptions in mind. The biggest difference between internal >> functions and userland functions in the context of this RFC is that with >> userland functions, we're starting with a clean slate. There are no type >> hint definitions anywhere, developers can selectively add them as they see >> fit. With internal functions, we have type requirements EVERYWHERE already, >> but with semantics that didn't take strict typing into account at all and >> evolved for almost 20 years. Strict typing the way it is now would >> radically change these semantics overnight, and will make the adoption of >> strict a much bigger headache than it can be, as I believe Rasmus >> demonstrated. >> >> I think addressing these issues could get us a LOT closer to consensus and >> make a lot of those who voted 'no' on v0.3 vote yes on v0.4. > So, if you'll permit me to summarize your message. The following > would be palatable to you? > > * Lossless coercion. This would sit somewhere between strict types > and weak types as lossy conversions (object->__toString() for objects > passed where string expected, any->bool) would be disallowed, but > lossless conversions (numeric strings to number types, int to float, > whole floats to ints, numbers to strings -- But no implicit > conversions to bools, no non-numeric strings to numerics, etc...) > > * Exclude internal functions from the strict switch. (Perhaps have a > separate switch for internal functions at a later date) > > With option to introduce features such as the following at a later date: > > * Union types (e.g. function foo((int | float) $value): (bool | string) { .... }) > * Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as > standard (like numeric), others user-definable) > > -Sara