On Fri, Jun 21, 2024 at 4:50 PM Rowan Tommins [IMSoP]
<[email protected]> wrote:
>
> Le 21/06/2024 à 14:27, Robert Landers a écrit :
>
> This is why I wanted to work on "as" part of the pattern matching. It
> isn't clear what will happen with the actual pattern matching RFC
> (yet), but being able to do:
>
> some_function_expecting_int($_GET['foo'] as ?int);
>
>
>
> I've started drafting a proposal for strict casts - independent of the pattern matching
> effort, but might be combinable - but the devil's in the details of exactly when the cast
> should fail, and what should happen when it does.
>
> For instance, should cast('abc' as ?int) fail, or default to null? Do we need
> different syntax for both? I have some thoughts, but haven't quite settled on a full proposal
> yet.
I know we have different opinions about many things, but I'd actually
love to help if you'd want it. I think our different opinions might
make it better. :)
I vaguely remember our last conversation about this and I kinda liked
your 'catch' thing. IIRC, it looked something like:
'abc' as ?int otherwise false;
or something (pretty sure it wasn't "otherwise") where if it wasn't an
int|null, it would fall back to false. If there wasn't a fallback, it
was a TypeError or something?
One thing nice about "as" is that having typed variables becomes much
more simpler to implement (if anyone wanted to implement it) even as a
transpilation step:
int $x = 5;
$x += "10"; // type error
gets transpiled to:
$x = 5 as int;
$x += "10" as int;
Interesting stuff.
>
> On Fri, 21 Jun 2024, at 13:46, Pierre wrote:
>
>
> And how about:
>
> some_function_expecting_int(\intval($_GET['foo']));
>
>
>
> intval($foo) and (int)$foo do exactly the same thing; they're basically just different
> syntax.
>
>
>
> And moreover, I'd write something like this, but:
>
> function validate_int(mixed $value): int { ...
>
>
>
> Which is why I included the word *concise*: it shouldn't be necessary for every user to
> write or install a custom function for such a common requirement.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
Robert Landers
Software Engineer
Utrecht NL