Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84864
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NpubMthM7fnhcG1qLFdaB+tH8OvfFURDUGbNS6sb=fkhQ@mail.gmail.com>
References: <BLU436-SMTP234CAFED9639237DE430B18E2190@phx.gbl>
	<325E0097-FD7E-4997-A95D-20C62368E162@zend.com>
	<55031C54.6060802@eliw.com>
	<CAMc0WS5MJ_RAtNO47R4wQjy8_YSDzzZeGECLUnzSVOAmB2JyPw@mail.gmail.com>
	<CAFp73Xtk4-o=DjipY4niopmgg+JC+Yyju_oxUWKWEHqMgQoiOA@mail.gmail.com>
	<7CE491F0-C243-4788-ADA2-5DA9DF1D1168@php.net>
	<d40df0c5636fccd2dd672ad1a4b72ced@mail.gmail.com>
	<CAEPJdukMnxn+Rjxy7tN0oSfoD_ryNwKDRLjJF6AAwGoWGH8WQA@mail.gmail.com>
	<332304ae552bfc635f999a8d73b505f0@mail.gmail.com>
	<CAEZPtU7Yv4T2YJYm9B3jyoro+28opg1XtcrZAT9+ZTmVFkq4Cg@mail.gmail.com>
	<CAMc0WS5+AwBuyqE4BobM_MaR97gWPQQm+Ot2k1Jja+69JBTBHw@mail.gmail.com>
	<85d81405ee1791efadea83cf734ebce3@mail.gmail.com>
	<CAAyV7nF81EPPEwcomFsiwr_8KQOnWdwJ5E8_aCoJqUzF5pNAdw@mail.gmail.com>
	<BLU436-SMTP5196EEC16BA57867D2DB25E2050@phx.gbl>
	<CAFMT4NpubMthM7fnhcG1qLFdaB+tH8OvfFURDUGbNS6sb=fkhQ@mail.gmail.com>
Date: Sun, 15 Mar 2015 19:16:50 +0100
Message-ID: <CANUQDCi8fqf70gHXvVeL3aM2zoLdM=6z28BPWN4+1cBMp4cq1w@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Bob Weinand <bobwei9@hotmail.com>, Anthony Ferrara <ircmaxell@gmail.com>, 
	Zeev Suraski <zeev@zend.com>, Stelian Mocanita <stelianm@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
From: me@kelunik.com (Niklas Keller)

2015-03-15 19:13 GMT+01:00 Levi Morrison <levim@php.net>:
> On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand <bobwei9@hotmail.com> wrote=
:
>>> Am 15.03.2015 um 18:48 schrieb Anthony Ferrara <ircmaxell@gmail.com>:
>>>
>>> Andrea's RFC had the following wording:
>>>
>>>> The only exception to this is the handling of NULL: in order to be con=
sistent with our existing type hints for classes, callables and arrays, NUL=
L is not accepted by default, unless the parameter is explicitly given a de=
fault value of NULL. This would work well with the draft Declaring Nullable=
 Types RFC.
>>>
>>> This proposal has a different behavior here. It explicitly allows
>>> nulls for types:
>>>
>>> function foo(int $abc) { var_dump($abc); }
>>>
>>> Unlike my proposal and any of Andrea's, calling foo(null) will be
>>> int(0) instead of an error.
>>>
>>> This is an important distinction as it basically undermines any
>>> attempt at a nullable RFC, since it makes primitives implicitly
>>> nullable.
>>>
>>> Anthony.
>>
>> Anthony,
>>
>> I think you've got something wrong there. It won't undermine an attempt =
at a nullable RFC.
>>
>> In the weak scalar typing world, nullables won't change what we accept, =
but what we receive.
>>
>> function (int|null $abc) { var_dump($abc); }
>> (or ?int or whatever syntax we will use)
>>
>> would allow null to *not* be casted here.
>> Means foo(null) will lead to $abc being null and not int(0) with that si=
gnature.
>
> I think allowing `null` for an `int` is an error. Converting a null to
> zero on a type boundary is harmful in my opinion.

I agree, `null` shouldn't be allowed for `int`.

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>