Re: [RFC] Basic Scalar Types

From: Date: Sun, 15 Mar 2015 18:16:50 +0000
Subject: Re: [RFC] Basic Scalar Types
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  Groups: php.internals 
Request: Send a blank email to internals+get-84864@lists.php.net to get a copy of this message
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 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 >

« previous php.internals (#84864) next »