Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105213
MIME-Version: 1.0
References: <CAC5V6gh79y-i1cQ-XhDBiZTq5BNLDbpcHxNX22mXtYKYrCC94g@mail.gmail.com>
 <CAF+90c90dRCU=iUCUhV95yyUbkKGOnM-p=UkMOoQXiCDY0kutg@mail.gmail.com>
 <CAG9XoMSSJ+ODhaQR3U=VFe5Tbh_YvRRtSwCx6kzuEHSRUozJfA@mail.gmail.com>
 <5cadfed8.1c69fb81.31f7d.1c49SMTPIN_ADDED_MISSING@mx.google.com>
 <CAC5V6ggkV9vp_Xg0MHiLGv8TAMk+9iDR9W4wxO+HO70u1h=7uw@mail.gmail.com> <5cae100d.1c69fb81.548c.48a4SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5cae100d.1c69fb81.548c.48a4SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 10 Apr 2019 18:15:46 +0200
Message-ID: <CAG9XoMSW-_Kq0Sio2NPYcQ4yHk1vPJz2jQ7awURa+w7mZ94FZw@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000085323005862f6258"
Subject: Re: [PHP-DEV] [RFC] Nullable Casting
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000085323005862f6258
Content-Type: text/plain; charset="UTF-8"

>
> I believe returning null in those situations makes the most intuative
> sense, yes.



No offense, but how can casting semantics different from those already used
in implicit casting be intuitive?

    function a(int $x) { var_export($x); }
    function b(?int $x) { var_export($x); }

    a("123"); // 123
    a(null); // TypeError
    a("abc"); // TypeError

    b("123"); // 123
    b(null); // NULL
    b("abc"); // TypeError

IMO, the only reasonable choice is therefore:

    (int) "123"; // 123
    (int) null; // TypeError
    (int) "abc"; // TypeError

    (?int) "123"; // 123
    (?int) null; // NULL
    (?int) "abc"; // TypeError

At least, if we want to fix the current behaviour, and not introduce
another inconsistency.
In other words, *strictly apply to explicit casting the rules of implicit
casting when strict_types is disabled*.

--
Ben

--00000000000085323005862f6258--