Re: Proposal: AS assertions

From: Date: Fri, 22 Mar 2024 20:05:58 +0000
Subject: Re: Proposal: AS assertions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14  Groups: php.internals 
Request: Send a blank email to internals+get-122733@lists.php.net to get a copy of this message
On Fri, Mar 22, 2024 at 8:02 PM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On Fri, 22 Mar 2024, at 17:38, Claude Pache wrote: > > > Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> a écrit : > > $optionalExpiryDateTime = $expiry as ?DateTimeInterface else some_other_function($expiry); > assert($optionalExpiryDateTime is ?DateTimeInterface); // cannot fail, already asserted by the > "as" > > > I think that the is operator is all we need; the > as operator adds syntax complexity for little gain. Compare: > > $optionalExpiryDateTime = $expiry as ?DateTimeInterface else some_other_function($expiry); > > vs > > $optionalExpiryDateTime = $expiry is ?DateTimeInterface ? $expiry : > some_other_function($expiry); > > > > I agree, it doesn't add much; and that's what the draft RFC Ilija linked to says as > well. > > But the point of that particular example is that after the "is" version, you > don't actually know the type of $optionalExpiryDateTime without looking up the return type of > some_other_function() > > With the "as" version, you can see at a glance that after that line, > $optionalExpiryDateTime is *guaranteed* to be DateTimeInterface or null, which I understood to be > the intention of Robert's original proposal on this thread. > > -- > Rowan Tommins > [IMSoP] > Indeed, "as" is to pattern matching like the fn is to function. You can live with one or the other, but having both is much more useful.

« previous php.internals (#122733) next »