[RFC] Nullable Casting View as Markdown

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

We are looking forward to your feedback and, if possible, help to fill
in the "RFC Impact" subsections (hopefully "None" to all) as well as a
review of the proposed implementation:

https://github.com/php/php-src/pull/3764

Thank you,

--
Guilliam Xavier

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, people could do something like this:

function castToIntOrNull($value)
{
if ($value === null) {
return null;
}

return (int)$int;

}

register_cast_function('?int', 'castToIntOrNull');

$x = (?int)getIntOrNull();

Additionally, it was requested on the mailing list to consider adding
support of nullable types to the settype() function,
e.g. settype($variable, "?int")

Someone probably needs to make an argument for it to be in core,
rather than just saying that it's something that could be done.

cheers
Dan
Ack

Real world example:

class Paginator {
// If null, will use the default value (eg. 15), else, it will requires
an int.
public function setItemsPerPage(?int $itemsPerPage) { ... }
}

// Info that came from user input.
// It will be a string, and not a integer, like we need.
$itemsPerPage = Input::get('itemsPerPage');

// If '<empty>' then $itemsPerPage = string '<empty>'
// If '123' then $itemsPerPage = string '123'

$paginator->setItemsPerPage($itemsPerPage); // Error: expected int, got
string.

Current solution:

$itemsPerPage = Input::get('itemsPerPage') ?: null;
$itemsPerPage = $itemsPerPage !== null ? (int) $itemsPerPage : null;

$paginator->setItemsPerPage($itemsPerPage); // OK

With this new feature: just...

$paginator->setItemsPerPage((?int) Input::get('itemsPerPage')); // OK

Question: why just not check if $itemsPerPage is set like:

$itemsPerPage = Input::get('itemsPerPage');

if ($itemsPerPage) {
$paginator->setItemsPerPage((int) $itemsPerPage); // OK
}

Answer: because in this example we could do that (although the new solution
is much more practical). In another case, I have a static factory method
that depends of an ?int to be created, and I can't just skip it with an
if() if user input is empty.

And about "settype($variable, "?int")" it was requested on original mailing
by Claude Pache.

Em dom, 7 de abr de 2019 às 23:54, Dan Ackroyd Danack@basereality.com
escreveu:

On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier guilliam.xavier@gmail.com
wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, people could do something like this:

function castToIntOrNull($value)
{
if ($value === null) {
return null;
}

return (int)$int;

}

register_cast_function('?int', 'castToIntOrNull');

$x = (?int)getIntOrNull();

Additionally, it was requested on the mailing list to consider adding
support of nullable types to the settype() function,
e.g. settype($variable, "?int")

Someone probably needs to make an argument for it to be in core,
rather than just saying that it's something that could be done.

cheers
Dan
Ack

--
David Rodrigues

register_cast_function('?int', 'castToIntOrNull');

I would quite oppose such a generic implementation, as it might have
unexpected consequences in other parts of the codebase : it's a global
configuration set at runtime.

I quite like the idea of nullable casting though, as I've come across a few
cases myself where this would have been useful and would have made the code
more concise/readable.

Ben

On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier guilliam.xavier@gmail.com
wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, people could do something like this:

function castToIntOrNull($value)
{
if ($value === null) {
return null;
}

return (int)$int;

}

register_cast_function('?int', 'castToIntOrNull');

$x = (?int)getIntOrNull();

Additionally, it was requested on the mailing list to consider adding
support of nullable types to the settype() function,
e.g. settype($variable, "?int")

Someone probably needs to make an argument for it to be in core,
rather than just saying that it's something that could be done.

cheers
Dan
Ack

register_cast_function('?int', 'castToIntOrNull');

I would quite oppose such a generic implementation, as it might have
unexpected consequences in other parts of the codebase : it's a global
configuration set at runtime.

I quite like the idea of nullable casting though, as I've come across a few
cases myself where this would have been useful and would have made the code
more concise/readable.

Ben

On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier guilliam.xavier@gmail.com
wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, people could do something like this:

function castToIntOrNull($value)
{
if ($value === null) {
return null;
}

return (int)$int;
}

register_cast_function('?int', 'castToIntOrNull');

$x = (?int)getIntOrNull();

Additionally, it was requested on the mailing list to consider adding
support of nullable types to the settype() function,
e.g. settype($variable, "?int")

Someone probably needs to make an argument for it to be in core,
rather than just saying that it's something that could be done.

cheers
Dan
Ack

--

I’ve come across this pattern (string variable contains a number or nothing) myself, but it also then makes me think - if your target ’type’ is ?int and you pass an empty string, wouldn’t you expect to get null rather than 0 ?

if your target ’type’ is ?int and you pass an empty string, wouldn’t
you expect to get null rather than 0 ?

I'd personally expect an Error, but this is not very much in line with
current casting semantics.

You have a point here, there is no clear answer for this edge case.

Maybe before nullable casting, should be discussed throwing errors when
attempting to cast a bad value, such as (int) "" ?
I think we're getting one step closer with the string to number comparison
RFC https://wiki.php.net/rfc/string_to_number_comparison, which suggests
that "" != "0".

Ben

On 8 Apr 2019, at 16:35, Benjamin Morel benjamin.morel@gmail.com
wrote:

register_cast_function('?int', 'castToIntOrNull');

I would quite oppose such a generic implementation, as it might have
unexpected consequences in other parts of the codebase : it's a global
configuration set at runtime.

I quite like the idea of nullable casting though, as I've come across a
few
cases myself where this would have been useful and would have made the
code
more concise/readable.

Ben

On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier <guilliam.xavier@gmail.com

wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, people could do something like this:

function castToIntOrNull($value)
{
if ($value === null) {
return null;
}

return (int)$int;
}

register_cast_function('?int', 'castToIntOrNull');

$x = (?int)getIntOrNull();

Additionally, it was requested on the mailing list to consider adding
support of nullable types to the settype() function,
e.g. settype($variable, "?int")

Someone probably needs to make an argument for it to be in core,
rather than just saying that it's something that could be done.

cheers
Dan
Ack

--

I’ve come across this pattern (string variable contains a number or
nothing) myself, but it also then makes me think - if your target ’type’ is
?int and you pass an empty string, wouldn’t you expect to get null
rather than 0 ?

Hello,

looks like you are living in a pig stall; php would be benefit from type safety when explicitly required.

Regards.

Hi Moe,

It seems you:

i) accidentally hit reply, instead of reply all. This is an easy
mistake to make.

ii) Appear to be trying to compare me to a pig? I'm not sure that this
is contributes to a productive discussion. Technical arguments are
much better received than animal comparisons.

cheers
Dan
Ack

Question: why just not check if $itemsPerPage is set like:
...
Answer: because in this example we could do that (although the new solution is much more practical).

Well, I disagree on that. That code is perfectly fine to me, and
having more operators to understand and remember is harder than having
fewer operators to understand and remember.

Also, I have a suspicion that the reason why you think this might be
needed is that you're doing too much work outside Input::get. If you
made a separate function that for Input::getInt that did all the
work of casting the value to int when appropriate, you wouldn't have
to repeat all the work in the functions that are calling Input::get.
i.e. you're causing a lot of typing to be required to further process
the result of a function, when you should be making new function that
does more precisely what you want.

In another case, I have a static factory method that depends of an ?int to be created, and I can't just skip it with an if() if user input is empty.

But please can you post the actual use-case you need this for. Or
possibly update the RFC with that example. Currently, imo, the RFC is
just presenting an alternative syntax for something that is not 100%
needed.

I do kind of like the idea in the RFC, but I think it needs a better
argument for it.

cheers
Dan
Ack

btw, the code you posted as:

$itemsPerPage = Input::get('itemsPerPage');

if ($itemsPerPage) {
$paginator->setItemsPerPage((int) $itemsPerPage); // OK
}

isn't quite the same as what the RFC does, right? The code equivalent
for the RFC would be this I think:

$itemsPerPage = Input::get('itemsPerPage');
if ($itemsPerPage !== null) {
$itemsPerPage = (int)$itemsPerPage;
}
$paginator->setItemsPerPage($itemsPerPage);

which even avoids the magic/horribleness of having to understand what
PHP thinks is empty.

Le 8 avr. 2019 à 12:24, Stephen Reay php-lists@koalephant.com a écrit :

if your target ’type’ is ?int and you pass an empty string, wouldn’t you expect to get null rather than 0 ?

You should get the same value than you get in:

declare(strict_types=0);

function foo(?int $x) {
    return $x;
}

foo("");

BTW, this is an argument to the have nullable casting functionality in core, rather than leave each developer to craft their own solution. Because PHP does already such nullable castings in several occasions (typed parameters, typed return values, and soon typed class properties, when you are in strict_types=0 mode), we should offer the programmers a built-in evident way to do the same type of casting, with the same semantics in occasion they want to do it manually. Otherwise, one developer will decide to map the empty string to null, the other to 0 and the third to NAN, and they get problems when they refactor the code in a way that a manual casting is replaced by an automatic implicit casting or vice versa, and the semantics differs on some cases.

—Claude

Le 8 avr. 2019 à 07:05, David Rodrigues david.proweb@gmail.com a écrit :

And about "settype($variable, "?int")" it was requested on original mailing
by Claude Pache.

PHP has several ways to perform casting:

1. (int) $foo
2. settype($foo, 'int');
3. intval($foo)

They are occasions where the programmer will prefer one method to the other. For example:

1. foo((int) $bar)
2. settype($someNonTrivial[$expr]['ession'], 'int');
3. array_map('intval', $foo)

The intval($foo) family of functions might be replaced by function ($foo) { return (int) $foo; } (or maybe soon by fn($foo) => (int) $foo), so that it might not be a necessity to double them with intvalIfNotNull($foo), etc. functions (also, finding a good name is not evident). But as for settype(), it cannot be replaced by casting syntax in case the target type is not written literally in source code; so that we should continue to fully support it. (And see https://externals.io/message/103779#103805 https://externals.io/message/103779#103805 for real world usages.)

—Claude

On Mon, Apr 8, 2019 at 6:05 AM David Rodrigues david.proweb@gmail.com
wrote:

Current solution:

$itemsPerPage = Input::get('itemsPerPage') ?: null;
$itemsPerPage = $itemsPerPage !== null ? (int) $itemsPerPage : null;

$paginator->setItemsPerPage($itemsPerPage); // OK

With this new feature: just...

$paginator->setItemsPerPage((?int) Input::get('itemsPerPage')); // OK

Question: why just not check if $itemsPerPage is set like:

$itemsPerPage = Input::get('itemsPerPage');

if ($itemsPerPage) {
$paginator->setItemsPerPage((int) $itemsPerPage); // OK
}

Answer: because in this example we could do that (although the new solution
is much more practical). In another case, I have a static factory method
that depends of an ?int to be created, and I can't just skip it with an
if() if user input is empty.

Hi!

I'm not a fan of the approach for a few reasons:

• First and foremost, we would introduce a cast where you can't be sure of
  what you'll get back. I understand the use-case for when you want to pass
  something to a nullable parameter, but if you think about this cast in
  isolation, it hardly makes sense.
• Second, maybe this is particular to your example, but your are forcing
  yourself to process something that the user didn't set. If your paginator
  already has a sane default(15) in a property, just don't call its setter
  when the user didn't ask you to. If you insist that you really want to save
  LoC, just assume that 0 means "use the default" and you can use the cast in
  all cases.

Regards,
Pedro

Hello,

i) was intentional.

ii) Not our fault, we do not have this function in our code-base and won't
ever; we would not even dare 8).

Cheers!

Hello,

looks like you are living in a pig stall; php would be benefit from type
safety when explicitly required.

Regards.

Hi Moe,

It seems you:

i) accidentally hit reply, instead of reply all. This is an easy
mistake to make.

ii) Appear to be trying to compare me to a pig? I'm not sure that this
is contributes to a productive discussion. Technical arguments are
much better received than animal comparisons.

cheers
Dan
Ack

[redacted]

[redacted]

[redacted]

As the initiator of this thread (who hasn't had the time to answer
questions yet, sorry), I would ask everyone to please try to avoid
sarcasm and provocation (intentional or not), especially if you
actually like the idea =(

Thank you in advance

--
Guilliam Xavier

Dan Ackroyd Danack@basereality.com wrote:

I'm guessing you don't actually have ths function getIntOrNull() in
your code-base? To help me understand where this would be useful,
could you provide some 'real-world' code where this would be useful?

Hello, thanks for digging in :)

Here's a "real-world" situation I happened to come across (NOTE:
simplified for sanity):

vendor/bar/api/src/Dest.php (code we don't own):

<?php
namespace Bar\Api;
interface Dest {
    public function send(?string $reference, string $label, /* ... */);
}

vendor/foo/api/src/Source.php (code we can't modify either):

<?php
namespace Foo\Api;
interface Source {
    public function getNumber(): ?int;
    public function getName(): string;
    /* ... */
}

src/Service.php (our code):

<?php
declare(strict_types=1); // FIXME
namespace App;
use Bar\Api\Dest;
use Foo\Api\Source;
class Service {
    public function action(Dest $dest, Source $source) {
        $dest->send(/* FIXME */ $source->getNumber(),

$source->getName(), /* ... */);
}
}

As you can see, it's actually pretty close to the RFC example; I'm not
sure it's worth to add complexity...

But please can you post the actual use-case you need this for. Or
possibly update the RFC with that example. Currently, imo, the RFC is
just presenting an alternative syntax for something that is not 100%
needed.

You have a point, but all the current alternatives I can think of
(namely: use a ternary (or an if), possibly with a temporary
variable; write (and autoload) custom casting functions; or give up on
strict typing) suffer one or more of the following downsides:

• increased risk of mistakes
• verbosity / more maintenance
• performance overhead

I do kind of like the idea in the RFC, but I think it needs a better
argument for it.

For your other points, I find that Claude Pache has given pretty good
arguments in the meantime (thanks!) =) (By the way, I also thought
about say, "nullable_intval()", "nullable_strval()" etc. but we're
missing "arrayval()" and "objectval()"...)

Best regards,

--
Guilliam Xavier

I do kind of like the idea in the RFC, but I think it needs a better
argument for it.
For your other points, I find that Claude Pache has given pretty good
arguments in the meantime (thanks!) =) (By the way, I also thought
about say, "nullable_intval()", "nullable_strval()" etc. but we're
missing "arrayval()" and "objectval()"...)

The debate as always is between those for who 'NULL' is a key STATE that
is part of the interaction between a database and program and those who
do not have that need. In my world a variable has a number of states and
NULL is simply one of them. Thinking of NULL as 'uninitialized' is a
reasonable match, and when pushing a variable to a database it's NULL
state can be used to trigger loading a default value or to leave the
field unset for later handling. HAVING to put a value or a string into
the variable because 'it must have a type' is simply wrong. But the need
now to HAVE to cast at times is equally wrong? I'm still hitting errors
in stuff being moved to 7.2 where the 'fix' is adding a cast, to keep
PHP happy, but then the value may well be a NULL return from the data
set so one almost ends up needing two versions of a variable ... one to
keep the now stricter typing happy and one to store the actual data
returned from the database. This also links up with the leading and
trailing spaces discussion. That the working value is a left justified
or right justified number but the logic now requires an 'int' to keep it
quiet is pushing towards needing these separate versions of essentially
the same variable :( Making the associative array view of the data
difficult to manage ...

--
Lester Caine - G8HFL

Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

On Sat, Apr 6, 2019 at 9:53 AM Guilliam Xavier guilliam.xavier@gmail.com
wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

We are looking forward to your feedback and, if possible, help to fill
in the "RFC Impact" subsections (hopefully "None" to all) as well as a
review of the proposed implementation:

https://github.com/php/php-src/pull/3764

I'm a bit concerned that there are two possible semantics for what (?int)
does:

1. What I would intuitively expect: A fallible integer cast. I.e. try to
   cast to integer and if not possible return null. So (?int) "foobar" becomes
   null rather than 0.
2. What this RFC proposes: A normal integer cast that leaves null alone.

Both behaviors make sense to me generally ... and if there are two ways to
interpret a piece of syntax, I'd say the syntax is not explicit enough.

Nikita

I'm a bit concerned that there are two possible semantics for what (?int)
does:

There is only one, if we align the semantics of explicit and implicit
casting: you wouldn't expect this:

function test(?int $bar) { var_export($bar); }
test("abc");

...to output 'null'?

--
Ben

There is only one, if we align the semantics of explicit and implicit
casting: you wouldn't expect this:

 function test(?int $bar) { var_export($bar); }
 test("abc");

...to output 'null'?

(Continuing from my previous post in a different thread...)

IMHO a cast such as ([?]type) would be better described as passing a
mixed value through a function which has a return type of whatever is in
the cast... the mechanics of that function determine what is returned,
so long as it conforms to the cast type.

A cast should always either return a value that would be accepted by a
function argument of an identical type to the cast, or it should throw
an exception.

function x(T $value) { ... }
x(T) - Always OK
x((T)$var) - Always OK
x($var) - Function may throw a TypeError if it cannot be converted in a
very strict manner.

To my mind, (?int) is quite explicit, in that it returns an integer or
null, and it is quite logical to expect it to return null in lieu of
throwing a TypeError if a conversion is not possible. Naturally,
(?int)null would return null.

I see a lot of potential use in (?int)$value ?? $default.

Equally I see a lot of use in the following to nullify unexpected inputs
such as if $_GET['something'] was an array:

$input = (?string)$_GET['input'] ?? '';

--
Mark Randall

I'm a bit concerned that there are two possible semantics for what (?int)
does:

1. What I would intuitively expect: A fallible integer cast. I.e. try to
   cast to integer and if not possible return null. So (?int) "foobar" becomes
   null rather than 0.
2. What this RFC proposes: A normal integer cast that leaves null alone.

Both behaviors make sense to me generally ... and if there are two ways to
interpret a piece of syntax, I'd say the syntax is not explicit enough.

The syntax mirrors nullable type declarations, but the thing is
implicit and explicit conversions don't always behave the same today:

<?php
declare(strict_types=0); // weak mode
error_reporting(-1);

$non_numeric_string = "foobar";

var_dump(array_slice([1,2,3], $non_numeric_string, null, true)); //
Warning, then prints `NULL`
var_dump(array_slice([1,2,3], 0, $non_numeric_string, true)); //
prints `array(0) { }`

var_dump(mb_substr("abc", $non_numeric_string, null, "UTF-8")); //
Warning, then prints `NULL`
var_dump(mb_substr("abc", 0, $non_numeric_string, "UTF-8")); //
Warning, then prints `NULL`

var_dump(+$non_numeric_string); // Warning, then prints `int(0)`
// (I can't think of a nullable equivalent for unary +)

(function (int $x) { var_dump($x); })($non_numeric_string); // TypeError
(function (?int $x) { var_dump($x); })($non_numeric_string); // TypeError

var_dump((function ($x): int { return $x; })($non_numeric_string)); // TypeError
var_dump((function ($x): ?int { return $x; })($non_numeric_string));
// TypeError

var_dump((int) $non_numeric_string); // prints `int(0)`
var_dump((?int) $non_numeric_string); // ...what would you expect?

--
Guilliam Xavier

(Continuing from my previous post in a different thread...)

IMHO a cast such as ([?]type) would be better described as passing a
mixed value through a function which has a return type of whatever is in
the cast... the mechanics of that function determine what is returned,
so long as it conforms to the cast type.

A cast should always either return a value that would be accepted by a
function argument of an identical type to the cast, or it should throw
an exception.

function x(T $value) { ... }
x(T) - Always OK
x((T)$var) - Always OK
x($var) - Function may throw a TypeError if it cannot be converted in a
very strict manner.

To my mind, (?int) is quite explicit, in that it returns an integer or
null, and it is quite logical to expect it to return null in lieu of
throwing a TypeError if a conversion is not possible. Naturally,
(?int)null would return null.

I see a lot of potential use in (?int)$value ?? $default.

Equally I see a lot of use in the following to nullify unexpected inputs
such as if $_GET['something'] was an array:

$input = (?string)$_GET['input'] ?? '';

So, for example:

$obj = (object) ["foo" => 42];


(function (int $x) { var_dump($x); })($obj); // TypeError
(function (?int $x) { var_dump($x); })($obj); // TypeError

var_dump((function ($x): int { return $x; })($obj)); // TypeError
var_dump((function ($x): ?int { return $x; })($obj)); // TypeError

var_dump((int) $obj); // Notice, then prints `int(1)`
var_dump((?int) $obj); // would you want it to print `NULL`?


(function (string $x) { var_dump($x); })($obj); // TypeError
(function (?string $x) { var_dump($x); })($obj); // TypeError

var_dump((function ($x): string { return $x; })($obj)); // TypeError
var_dump((function ($x): ?string { return $x; })($obj)); // TypeError

var_dump((string) $obj); // Recoverable fatal error
var_dump((?string) $obj); // would you want it to print `NULL`?

I have no clear answer myself (other than the current proposal)...

--
Guilliam Xavier

var_dump((?int) $obj); // would you want it to print NULL?
var_dump((?string) $obj); // would you want it to print NULL?

I believe returning null in those situations makes the most intuative
sense, yes.

var_dump((int) $obj); // Notice, then prints int(1)

In the absense of a nullable modifier, that makes so little sense that
it definitely needs to throw a TypeError IMO.

--
Mark Randall

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

No offense, but how can casting semantics different from those already used
in implicit casting be intuitive?

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.

Function arguments specify what goes in to a function, whereas casts
and return types specify what comes out of the function.

I would still expect the following:

function x(): ?int { return "foo"; } // TypeError because return is
effectively a function

function x(): ?int { return (int?)"foo"; } // null

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.

--
Mark Randall

Function arguments specify what goes in to a function, whereas casts
and return types specify what comes out of the function.

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 still expect the following:
function x(): ?int { return "foo"; } // TypeError because return is
effectively a function
function x(): ?int { return (int?)"foo"; } // null

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 @.

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 can't find a use case on top of my head, where I usually want to silence
a failed conversion, other than user input validation; and I don't think
type casts are specifically designed for this purpose.
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,
but having (?int) do this job is IMHO a bad idea which does not help moving
the language towards better consistency.

• Ben

No offense, but how can casting semantics different from those already
used
in implicit casting be intuitive?

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.

Function arguments specify what goes in to a function, whereas casts
and return types specify what comes out of the function.

I would still expect the following:

function x(): ?int { return "foo"; } // TypeError because return is
effectively a function

function x(): ?int { return (int?)"foo"; } // null

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.

--
Mark Randall

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

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

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

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.

It's an interesting discussion and I appreciate you engaging on it.

I wonder, perhaps, if the goals of your initial RFC could be achieved by
a single operator?

If your intent is to pass through null and convert everything else, then
it seems to me what you're really after is a reverse null coalescing
operator, a binary operator that takes the right hand side only if the
left hand side is not null, although I'm struggling to think of any
character combination to represent it.

Although you have to write the variable twice, it seems more generic...
Admittedly I'm unsure which real-world cases it would be relevant to.

$nullable_number = $maybe_null ^?? (int)$maybe_null;

Personally I would have maybe approached it a different way and changed
casting itself to contain an ordered list, where the first convertible
match is returned.

$nullable_number = (null|int)$input;

$input is null, null is a legit cast to null, so matches first condition
and returns null. Otherwise moves on to next option and casts it to an
integer.

--
Mark Randall

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

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!

Don't stress yourself about it. At the end of the day we're all just
here because we want to improve the language, and a person's willingness
to debate the pros and cons, and adjust if necessary, is naturally a
extremely valuable part of the RFC authoring process.

When you eventually call the vote itself, regardless of whether it
passes or fails, you should both be holding your heads high that you've
made the effort.

--
Mark Randall

On Sat, Apr 6, 2019 at 9:52 AM Guilliam Xavier
guilliam.xavier@gmail.com wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

We are looking forward to your feedback [...]

Thank you,

Hello again internals,

Thanks everyone for your valuable feedback. I have updated the RFC
with a new Discussion section to [try to] summarize the various
arguments raised in this thread.

--
Guilliam Xavier

Discussion topic:

• Not 100% needed: is the same that says "nullable typehint is not 100%
  need because we can just check in time". This argument has no sense, once
  that PHP supports nullable casting for parameters typehint, and the
  nullable casting is just a way to fit the argument to parameter typehint
  that is already possible, but very hacky ($x !== null ? (string) $x : null
  vs. (?string) $x).

• What about e.g. nullable_intval()? intval() is a PHP 4 feature that could
  be replaced in 99% of cases by (int) cast. So nullable_intval() make no
  sense once that probabily it will be never used (except it (?int) will not
  be implemented, but if nullable_intval() could be, so is better (?int)
  instead).

• Fallible Casting: it should works exactly as current castings, but with
  possibility to be null if it is already null. For instance: (int) "string"
  currently will be int (0), by this way, so (?int) "string" should be int
  (0) too. The nullable casting will ONLY return NULL if the subject is NULL,
  exclusively in this case. So it will affects only (int) null that currently
  is int (0). So (?int) null will be null. Same for falsy values: (int) '' is
  currently int (0), so (?int) '' will be int (0) also.

• Alternative syntax (null|int): very ugly, no? :P Maybe on future it could
  be valid for multicasting eg. (string|int|float) $x, but this is subject to
  another topic.

• A cast where you can't be sure of what you'll get back: you will have the
  same sure that currently you have with (int) $x, with exception that
  nullable values are more explicit because "if $x is null, then you will get
  null with 100% of sure". For cases like: (int) 'string', (int) '123string'
  and (int) 'string123' what you got? (It is already supported by PHP):
  Answer: int (0), int (123) and int (0), respectively.

Em dom, 21 de abr de 2019 às 06:19, Guilliam Xavier <
guilliam.xavier@gmail.com> escreveu:

On Sat, Apr 6, 2019 at 9:52 AM Guilliam Xavier
guilliam.xavier@gmail.com wrote:

Hello internals,

David and I would like to open the discussion on our joint RFC:

https://wiki.php.net/rfc/nullable-casting

Mainly, it would enable to use e.g. (?int)$x besides (int)$x.

We are looking forward to your feedback [...]

Thank you,

Hello again internals,

Thanks everyone for your valuable feedback. I have updated the RFC
with a new Discussion section to [try to] summarize the various
arguments raised in this thread.

--
Guilliam Xavier

--
David Rodrigues