Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83011
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
Date: Tue, 17 Feb 2015 14:03:49 -0800
Message-ID: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Scalar Type Hints v0.4
From: pollita@php.net (Sara Golemon)

Based on conversations here and elsewhere on the internet, I'd like to
put forward a rough gameplan for scalar types which I hope addresses
most concerns.  This is back-of-the-napkin and I'm not asking for a
committed yes/no, just pre-rfc set of thoughts.

Please don't get hung up on specific names, we can debate those in the
coming week(s), I'm only looking for large architectural issues.

1) Introduce scalar types for primitives: bool, int, float, string,
resource, object (we already have array)
1a) Introduce meta-types as pre-defined unions (we can add custom
unions in a later rfc).  A possible list may be as follows (again, we
can argue what's in this list separately):
* mixed: any type
* scalar: (null|bool|int|float|string)
* numeric (int|float|numeric-string)
* stringish (string or object with __toString())
* boolish (like mixed, but coerces to bool)
* etc...

2) Define a way to enable "strict mode" (we'll be weak by default).

2a) Userspace impact:   Strict mode will throw a recoverable error on
type mismatch.  Weak mode will coerce the type according to conversion
rules (See #3), throwing a recoverable error if coercion isn't
possible.

2b) Internal impact:  The same rules apply to internal functions as
userspace functions HOWEVER, we use the types present in ZEND_ARG_INFO
structures, not zpp.  This has the net effect that every internal
function remains effectively untyped unless specifically opted in by
means of updating their arg info struct.  In weak mode, internal
functions coerce according to conversion rules.

3) Tighten up coersion rules for weak mode.  i.e. "10 dogs" for an int
is a violation, but "10" is acceptable.

3a) Userspace impact: We're in a clean slate state, so this is "safe"
from a BC perspective.

3b) Internal impact: Again, behavior remains unchanged unless the
ZEND_ARG_INFO struct has been modified to add proper typehints.  If
typehints have been added, then the more aggressive coersion rules
apply during typehint validation.

I really want to underline the design expressed in #2b and #3b.
zend_parse_parameters()'s types have been removed from the equation in
this proposal.  This means that, until someone audits a given function
and makes the decision to give it a type, it will effectively behave
as though always weak, regardless of the caller's flags.  This enables
us to give the same contractual behavior internally and externally,
while still implicitly treating internal functions as a bit special
for the purpose of moving forward.

-Sara