Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105231
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>
 <CAG9XoMRHka=YxTxKaMGpmYB3Kvhus+-V-HTYjtrJahQhCdC-cA@mail.gmail.com> <5cae8010.1c69fb81.af1d.9b9bSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5cae8010.1c69fb81.af1d.9b9bSMTPIN_ADDED_MISSING@mx.google.com>
Date: Thu, 11 Apr 2019 09:52:16 +0200
Message-ID: <CAC5V6giqcwutk_cKqhw0CmVqP2yhfH9NWh+=FaXL7dyfX9h5WA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Nullable Casting
From: guilliam.xavier@gmail.com (Guilliam Xavier)

OK, I'll try to sum up a bit the recent messages (since Nikita's one):

Mark Randall wrote:
> As is implied from the name, an implicit cast is done because the code
> needs it to, not because it has been told to by the caller. It is
> natural to be more conservative when doing something that has not been
> explicitly specified.
>
> I expect a difference in the behaviour of function arguments vs casts
> for the reason that although they share a type syntax, they do have two
> very different behaviours.

That makes sense!

> I don't think it would go down very well to have non-nullable casts
> throwing TypeErrors for common cases, without an elegant
> could-not-convert fallback that doesn't require a 5 line try-catch block.

I agree (and even for nullable casts). I'm also fine with the current
`(int)null === 0`, `(string)null === ""`, `(array)null === []` etc.
(Now maybe things like `(int)"abc" === 0` *could* emit some Notice
like already the case for `(string)[] === "Array"`, but that's another
discussion...)

Benjamin Morel wrote:
> Of course there could be helper functions with different semantics, that
> would perform a cast-or-null-on-failure, such as `to_int("abc") === null`

There was a "Safe Casting Functions" RFC, which was rejected (but that
was in 2014, before PHP 7 and scalar type declarations, so who knows
how it would go if re-proposed today...)

Mark Randall wrote:
>     $nullable_number = $maybe_null ^?? (int)$maybe_null;

That's an... "interesting" idea ^^ (though I would not propose it).

>     $nullable_number = (null|int)$input;

This is explicit, but I worry that `null|int` and `int|null` will be
different (since you propose *ordered*) whereas they're the same in
phpDoc as well as in the (rejected) "Union Types" RFC. (I also fear
things like `(null|float|int|string)$x`...)

***

The initial motivation behind the RFC was mainly to have an explicit
equivalent of "nullability-preserving" implicit *valid* conversions
in symmetry with nullable scalar type declarations and weak-typing mode
(e.g. `(?string) $int_or_null` or `(?int) $numeric_string_or_null`)
for use in strict-typing mode.

But there are indeed various combinations of "invalid" conversions
(although one could argue they are programming errors or bugs to fix),
and people seem to expect different things from a new "(?type)" cast
syntax (not to speak of the existing "(type)" cast) as how to handle
those "failures"...

Honestly as a newbie here I'm feeling more tired than I had expected
and I'm not sure if we'll find a syntax+semantics pair that will reach
a consensus... Suggestions and comments very welcome!

-- 
Guilliam Xavier