Re: [PHP-DEV] [RFC] Nullable Casting

  105225
April 10, 2019 21:30 benjamin.morel@gmail.com (Benjamin Morel)
> 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 > >
  105229
April 10, 2019 23:45 markyr@gmail.com (Mark Randall)
On 10/04/2019 22:30, Benjamin Morel wrote:
> 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