Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82928
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.215.54 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
	<016f01d04a3a$e9183220$bb489660$@php.net>
	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
Date: Mon, 16 Feb 2015 22:20:03 -0800
Message-ID: <CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: francois@php.net, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: pollita@php.net (Sara Golemon)

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