Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <011801d04a07$83ab1c00$8b015400$@php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
Date: Mon, 16 Feb 2015 12:57:12 -0700
Message-ID: <CAFMT4Nru-iuSvOjfAFCcnMOFbsPm+TtffeHrBjgiHDjHxLCgMw@mail.gmail.com>
To: francois@php.net
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Jefferson Gonzalez <jgmdev@gmail.com>, 
	Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: levim@php.net (Levi Morrison)

On Mon, Feb 16, 2015 at 9:42 AM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
> Hi,
>>
>> De : Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
>>
>> The 0.1 RFC version was mentioned a lot as a good compromise by many
>> people
>> and had major support.
>> Maybe someone competent could pick it up, make necessary adjustments
>> that
>> where required and let people vote on it? Start with small steps - get t=
he
>> weak type hints into the language first, see how it gets used and then w=
e
>> can always add strict type hints if there is a need/desire to do that.
>>
>> That way we finally get type hints into the language, and those wanting =
the
>> strict variety have all the opportunities in the world to add them at a
>> later release with proper discussion and development time.
>
> That's what I am planning. If I write an RFC, it will be based on Andrea'=
s 0.1/0.2 version, and won't propose different modes.
>
> The problem is that the previous controversial RFC focused people on weak=
 vs strict typing, while we should have explored other technical concerns. =
Here are the main ones I see :
>
> - the fact that the RFC supports single types only, like the previous 're=
turn type' RFC. While it is easier to implement, it opens several issues as=
 multiply-typed arguments are an integral part of the PHP language (mostly =
completeness and compatibility with internal function hinting). If we want =
to support multiple types the same way for internal and userspace functions=
, we must extend the ZPP layer to support it.
>
> - the mechanism to check for type hints on internal functions, while easy=
 to implement, is not sufficient, as a lot of internal functions get a bare=
 zval from the parsing system and then convert it by themselves. With the p=
roposed mechanism, there's no possible hinting on such argument, which will=
 make the implementation different from the documentation. Even if the chec=
k is done by the function body, it won't be done in a consistent way with t=
ype hinting checks and won't raise a similar error. As most cases are relat=
ed to multiply-typed args, the solution is in adding multiply-typed support=
 to ZPP. Multiply-typed support needs to redefine scalar conversion rules, =
to take care of the target type being a combination of single types.
>
> - We need to define the appropriate extension to Reflection parameters/re=
turn type. That's not complex, but it takes time.
>
> - Other changes I'd like to propose are exposed in Bob Weinand's article,=
 at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explai=
ns how restricting weak conversion possibilities would make strict typing a=
lmost useless. Changes include forbidding bool to int/float or '7years' to =
int. This cannot be left for future additions as BC breaks will make it imp=
ossible. To remain consistent between userspace/internal functions, this mu=
st also be done at the ZPP level.
>
> - Using bare class names as type hints is a potential issue too, as it ma=
kes reserved keywords and class names share the same naming space. I think =
we should deprecate the use of class names as type hints in favor of 'objec=
t(class-name)'. If we don't do that, every future addition of a type hint k=
eyword will cause a BC break (and will be practically impossible).
>
> - Additional 'hybrid' types like 'numeric' and 'mixed' should be also pro=
vided.
>
> So, most features I have in mind are really 'now or never'.
>
> My main concern, anyway, is with March 15 announced feature freeze. If we=
 need a vote by this date, it's impossible. And planning such BC for 7.1 is=
 probably unrealistic because of the huge syntax additions and BC breaks it=
 brings. So, if it's too late for an inclusion in 7.0, I think I'll give up=
.
>
> So, could someone confirm what 'feature freeze' exactly means ?
>
> Regards
>
> Fran=C3=A7ois
>
>
>
>
>
>
>
>
>  The main issues are completeness (we can give hints for some cases, but =
not for others) and, more important, the compatibility with internal functi=
ons. As Andrea herself agreed, her mechanism for type hinting on internal f=
unctions is not sufficient. Just using the ZPP macros, as they exist today,=
 won't work as a lot of internal functions get a bare zval and then convert=
 it by themselves. So, in this case, we would check nothing. So, an argumen=
t described as 'string|array' in the documentation, wouldn't produce the sa=
me sort of error when sent an object, than its friend, described as 'string=
'. This is not consistent and will open a lot of side effects if it is left=
 out of the type hint layer.

I have a sum types RFC that isn't ready for discussion. However, since
you have mentioned the functionality it here is the preliminary RFC:
https://wiki.php.net/rfc/sum_types.

Also, I know people REALLY want scalar types in PHP 7.0 but honestly
all we need to do is reserve the keywords so there is no BC impact and
then we can do it at any point during the PHP 7 lifecycle. This is my
preferred course of action, because right now this internals mailing
list is in HIGH STRESS MODE. I would rather just take the action of
reserving the types so it can be done in 7.1 (or 7.2 or even if it's
never, I would prefer to reserve these words).