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