Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82955
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Sara Golemon'" <pollita@php.net>,
	"'Zeev Suraski'" <zeev@zend.com>
Cc: "'PHP internals'" <internals@lists.php.net>
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> <CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
In-Reply-To: <CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
Date: Tue, 17 Feb 2015 13:57:30 +0100
Message-ID: <022801d04ab1$4a0c47d0$de24d770$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwEU0CpMAs0H7+idRbpdcA==
Content-Language: fr
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi Sara,

> De : php@golemon.com [mailto:php@golemon.com] De la part de Sara
> Golemon
>
> So, if you'll permit me to summarize your message.  The following
> would be palatable to you?
>=20
> * 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...)

1. it must be implemented as a modification to zpp conversion rules. =
IMHO, a third mode would be the worst thing to do.

2. It is not not about being lossless or not. People expect bool -> int =
to be disabled, for example, and it is not lossless.

3. It is more a question of finding a consensus about conversions which =
don't make sense, and disabling them. Examples include bool conversion =
to any other type and, of course, disabling trailing chars in numeric =
strings.

4. Once this is done, 99% of strict type proponents already said they =
would be OK with the so-called (not so) weak mode, making it possible to =
get rid of this far from perfect two-mode mechanism (actually, this =
two-mode approach more and more reminds me a great idea about bringing =
transparent Unicode support in PHP).

If future development tools require more precise types (and they =
probably will), the mechanism can be extended with new keywords, but the =
idea is never using the same keyword for different ways to check a zval. =
New keywords would be defined at the zpp level, keeping internal and =
userspace features in sync.

Would you agree proposing this as an option in 0.4 ? Actually, I will =
write it as a separate RFC as modifying zpp conversion rules has impacts =
well beyond type hinting. Then, type hinting RFCs can reference it.

> * Exclude internal functions from the strict switch. (Perhaps have a
> separate switch for internal functions at a later date)

This would make the feature inconsistent from an end user's pov.

If a user enables strict mode, he assumes strict checks for every =
function he calls. *We* know that userspace and internal functions use =
different mechanisms, but the end user doesn't have to know. From his =
pov, a function is a function. If the documentation states that the =
function he's calling in strict mode accepts int, he will expect int to =
be checked in strict mode. We cannot say 'Oh, wait, it's an internal =
function, the rules are not the same'. The distinction between internal =
and userpace functions is irrelevant for him and has to remain so.

So, from all these arguments, I now think that strict types, as defined =
in 0.3, are not the best solution.

> With option to introduce features such as the following at a later =
date:
>=20
> * 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)

As I told Zeev, union types can be kept for the future if we don't go =
the nullable road, as it would be too confusing making 'string|null' and =
'?string' synonyms.

The question of null is not so simple. IMO, it should be left for a =
future discussion about union types. Anyway, once people get used to =
scalar hinting, the need for union types will arise quickly.

Regards