Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105225
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>
 <CAG9XoMSW-_Kq0Sio2NPYcQ4yHk1vPJz2jQ7awURa+w7mZ94FZw@mail.gmail.com>
 <5cae1fec.1c69fb81.d2407.c20eSMTPIN_ADDED_MISSING@mx.google.com>
 <CAG9XoMRqjwgZZQ3Mw9jdyG4MS5Z0z=sCT-3raAHRb9FAmRw4+w@mail.gmail.com> <5cae2f86.1c69fb81.ce442.006eSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5cae2f86.1c69fb81.ce442.006eSMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 10 Apr 2019 23:30:28 +0200
Message-ID: <CAG9XoMRHka=YxTxKaMGpmYB3Kvhus+-V-HTYjtrJahQhCdC-cA@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000003f976058633c8d6"
Subject: Re: [PHP-DEV] [RFC] Nullable Casting
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000003f976058633c8d6
Content-Type: text/plain; charset="UTF-8"

> That's exactly what it is, and thanks to null coalescence, you then have
> an easy available ability to either check if it succeeded, or default to
> another value.

Your arguments are perfectly valid and make sense, I guess this is a matter
of not viewing different semantics for explicit and implicit cast as
inconsistencies.

- Ben

On Wed, 10 Apr 2019 at 20:01, Mark Randall <markyr@gmail.com> wrote:

> On 10/04/2019 18:34, Benjamin Morel wrote:
> > So why would you have different semantics for implicit `(?int)` cast vs
> `:
> > ?int` function return type cast, if they're both *out*?
> > Return type cast has the same semantics as parameter type cast.
>
> I would have to disagree with this as I think of "return" as a language
> construct function that takes one argument. When a return type is
> specified, that return function effectively inherits that type for its
> only argument, and limitations on implicit conversion should apply.
>
> > This looks weird to me. I would expect this last line to throw anyway.
> > Having "foo" passed somehow where your code expects an int(ish) or null,
> > should not be silenced and converted to NULL IMO.
> > To me, this last line just says "ignore any error here" - a bit like
> > prefixing it with @.
>
> That's exactly what it is, and thanks to null coalescence, you then have
> an easy available ability to either check if it succeeded, or default to
> another value.
>
> $items = (?int)$_GET['items'];
> if ($items === null) {
>     // it didn't just resort to 0, which might be perfectly valid
>     throw new Exception('Unsure how many items');
> }
>
> $value = (?string)$_GET['name'] ?? '';
> if ($value === '') {
>    // also, ?name[]= can sod off
>    throw new Exception('You must provide a name');
> }
>
> --
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00000000000003f976058633c8d6--