2015-03-15 19:13 GMT+01:00 Levi Morrison <le...@php.net>:
> On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>>> Am 15.03.2015 um 18:48 schrieb Anthony Ferrara <ircmax...@gmail.com>:
>>>
>>> Andrea's RFC had the following wording:
>>>
>>>> The only exception to this is the handling of NULL: in order to be
>>>> consistent with our existing type hints for classes, callables and arrays,
>>>> NULL is not accepted by default, unless the parameter is explicitly given
>>>> a default 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
>> signature.
>
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
