[RFC] Nullable Casting

  105122
April 6, 2019 07:52 guilliam.xavier@gmail.com (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`.

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
  105136
April 8, 2019 02:54 Danack@basereality.com (Dan Ackroyd)
On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier 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
  105137
April 8, 2019 05:05 david.proweb@gmail.com (David Rodrigues)
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 '' then $itemsPerPage = string ''
// 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 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
  105149
April 8, 2019 15:35 Danack@basereality.com (Dan Ackroyd)
On Mon, 8 Apr 2019 at 06:05, David Rodrigues proweb@gmail.com> wrote:
> > 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.
  105151
April 8, 2019 16:17 claude.pache@gmail.com (Claude Pache)
> Le 8 avr. 2019 à 07:05, David Rodrigues 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
  105153
April 8, 2019 17:46 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
On Mon, Apr 8, 2019 at 6:05 AM David Rodrigues 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
  105141
April 8, 2019 09:35 benjamin.morel@gmail.com (Benjamin Morel)
> 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 Mon, 8 Apr 2019 at 04:55, Dan Ackroyd <Danack@basereality.com> wrote:
> On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105143
April 8, 2019 10:24 php-lists@koalephant.com (Stephen Reay)
> On 8 Apr 2019, at 16:35, Benjamin Morel 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 Mon, 8 Apr 2019 at 04:55, Dan Ackroyd <Danack@basereality.com> wrote: > >> On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier 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 >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
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` ?
  105144
April 8, 2019 11:53 benjamin.morel@gmail.com (Benjamin Morel)
> 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 Mon, 8 Apr 2019 at 12:25, Stephen Reay <php-lists@koalephant.com> wrote:
> > > On 8 Apr 2019, at 16:35, Benjamin Morel 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 Mon, 8 Apr 2019 at 04:55, Dan Ackroyd <Danack@basereality.com> wrote: > > > >> On Sat, 6 Apr 2019 at 08:53, Guilliam Xavier 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 > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > 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` ? > > > > >
  105150
April 8, 2019 15:41 claude.pache@gmail.com (Claude Pache)
> 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: ```php 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
  105157
April 9, 2019 07:32 guilliam.xavier@gmail.com (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): 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
  105159
April 9, 2019 08:26 lester@lsces.co.uk (Lester Caine)
On 09/04/2019 08:32, Guilliam Xavier wrote:
>> 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
  105202
April 10, 2019 10:52 nikita.ppv@gmail.com (Nikita Popov)
On Sat, Apr 6, 2019 at 9:53 AM Guilliam Xavier 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
  105203
April 10, 2019 12:03 benjamin.morel@gmail.com (Benjamin Morel)
> > 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
  105207
April 10, 2019 14:33 markyr@gmail.com (Mark Randall)
On 10/04/2019 13:03, Benjamin Morel wrote:
> 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
  105208
April 10, 2019 14:40 guilliam.xavier@gmail.com (Guilliam Xavier)
On Wed, Apr 10, 2019 at 12:52 PM Nikita Popov ppv@gmail.com> wrote:
> > 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
  105321
April 21, 2019 09:19 guilliam.xavier@gmail.com (Guilliam Xavier)
On Sat, Apr 6, 2019 at 9:52 AM Guilliam Xavier
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
  105322
April 21, 2019 14:17 david.proweb@gmail.com (David Rodrigues)
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 > 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