Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
Date: Wed, 18 Feb 2015 13:10:59 +0000
Message-ID: <CAPwsocFUF9WcTxc-BjmaCccdPbeYs5VgyDvqYbx=3cR-SwoPkg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: leight@gmail.com (Leigh)

On 17 February 2015 at 22:03, Sara Golemon <pollita@php.net> wrote:
> 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)

Can we keep a 0) of "reserve names for future use in-case of RFC
failure" option.

> 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...

How do you propose weak typing works with these? Does it only allow
one of the union of types through (thus making it strict), or does it
try and coerce to one if it can? Which one does it pick?

> 2) Define a way to enable "strict mode" (we'll be weak by default).

Please give the option to enable strict by default. This is all many
of us have been asking for. Personally I don't care if this cannot be
changed from a script to prevent it being forced on users (yes I'd be
willing to have it as an ini setting even...). Just the option, that's
all we want.

> 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.

This leaves us in a state where some functions will have defined types
with their aggressive coersion rules and some will not, and we can't
expect users to remember which set of functions have been updated or
not. I think the rules need to apply to everything or nothing.

> 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.

So there will be potential ongoing breaks for any type of callers as
and when functions receive their types. No type is existing
behaviour(?), typed + weak is "aggressive coersion" that may fail
where untyped did not (from 3b), and typed + strict wont throw until
the function is typed.

Unrelated to the specifics of this proposal, I've had a quick search
(for things like "locale" and "LC_NUMERIC") but didn't see anything.
How do locale settings affect weak typing (specifically thinking
string -> float)?