Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84863 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52676 invoked from network); 15 Mar 2015 18:13:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2015 18:13:24 -0000 Authentication-Results: pb1.pair.com header.from=morrison.levi@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=morrison.levi@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.44 as permitted sender) X-PHP-List-Original-Sender: morrison.levi@gmail.com X-Host-Fingerprint: 209.85.218.44 mail-oi0-f44.google.com Received: from [209.85.218.44] ([209.85.218.44:33972] helo=mail-oi0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 67/66-29489-2CBC5055 for ; Sun, 15 Mar 2015 13:13:23 -0500 Received: by oier21 with SMTP id r21so21435571oie.1 for ; Sun, 15 Mar 2015 11:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=O7F9UvfQUPgQgJSxRH/Rk/IHYQF5nX4ZmNff+gLRuuw=; b=hKzDrSvsutZdyVdlrAJ0dgAFRFXZr2jXS2i6mRRcwFECQZ9wGt3djN/+EnzD1HtMO4 gWdN2JiZodZce+0tReDvABjOxxnl6BevpJDCm3LGU2yDkeasmqwiVEFJtuUOcZmClxqC HhNGptZpSNxTAXfsSNFCfCf331mO2/Bry6WneO28YlPnfpOXIvNa9KoTv6p0XGFgdn/L rvwbCLa1nuf3cziwdY/QQrLqoi2tySJ8qB4eQ4EV1qajsQi3nb51O+X/UNdqIkcJ4q0V 71Hjzw1HojCcLsQ2joXVK11BN8xwkCK2meLCYDAxkD32sgoQsmpfbgAbjOsy1+F80ylB 2p8w== MIME-Version: 1.0 X-Received: by 10.202.178.131 with SMTP id b125mr42420817oif.80.1426443200178; Sun, 15 Mar 2015 11:13:20 -0700 (PDT) Sender: morrison.levi@gmail.com Received: by 10.76.90.74 with HTTP; Sun, 15 Mar 2015 11:13:19 -0700 (PDT) In-Reply-To: References: <325E0097-FD7E-4997-A95D-20C62368E162@zend.com> <55031C54.6060802@eliw.com> <7CE491F0-C243-4788-ADA2-5DA9DF1D1168@php.net> <332304ae552bfc635f999a8d73b505f0@mail.gmail.com> <85d81405ee1791efadea83cf734ebce3@mail.gmail.com> Date: Sun, 15 Mar 2015 12:13:19 -0600 X-Google-Sender-Auth: DTMkk-cOUoUh05EGzg-9TC_v0kw Message-ID: To: Bob Weinand Cc: Anthony Ferrara , Zeev Suraski , Stelian Mocanita , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types From: levim@php.net (Levi Morrison) On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand wrote: >> Am 15.03.2015 um 18:48 schrieb Anthony Ferrara : >> >> Andrea's RFC had the following wording: >> >>> The only exception to this is the handling of NULL: in order to be cons= istent with our existing type hints for classes, callables and arrays, NULL= is not accepted by default, unless the parameter is explicitly given a def= ault 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 a= t a nullable RFC. > > In the weak scalar typing world, nullables won't change what we accept, b= ut 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 sig= nature. I think allowing `null` for an `int` is an error. Converting a null to zero on a type boundary is harmful in my opinion.