Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123735
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
 <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com> <350c1531-9bcf-4e7c-824b-8d9904b9e48e@rwec.co.uk>
 <CAPzBOBMw=Hn4SabAq0FeppLpQMwRJh2Ffc3JhhFFOps85XNazw@mail.gmail.com>
 <914cde73-3e53-44a8-94ff-bcf34000cc0c@processus.org> <CAPzBOBNtF=xBVRFEu3wZrMuktBV7bZzjbmBN=+6eu9qnewqmiw@mail.gmail.com>
 <84be04f2-73cd-4fdb-929d-724d4fea98fa@processus.org>
In-Reply-To: <84be04f2-73cd-4fdb-929d-724d4fea98fa@processus.org>
Date: Fri, 21 Jun 2024 18:12:36 +0200
Message-ID: <CAPzBOBNw-EpeMo4x=M18R3L86o0ss8Vc-4jojevS3YZphKeJJg@mail.gmail.com>
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
To: Pierre <pierre-php@processus.org>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Fri, Jun 21, 2024 at 5:49=E2=80=AFPM Pierre <pierre-php@processus.org> w=
rote:
>
> Le 21/06/2024 =C3=A0 15:57, Robert Landers a =C3=A9crit :
> > On Fri, Jun 21, 2024 at 3:01=E2=80=AFPM Pierre <pierre-php@processus.or=
g> wrote:
> >> Le 21/06/2024 =C3=A0 14:27, Robert Landers a =C3=A9crit :
> >>
> >> 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);
> >>
> >> And how about:
> >>
> >> some_function_expecting_int(\intval($_GET['foo']));
> >>
> >> And moreover, I'd write something like this, but:
> >>
> >> function validate_int(mixed $value): int {
> >>      if (null =3D=3D=3D $value || '' =3D=3D=3D $value) {
> >>          return null;
> >>      }
> >>      if (\is_int($value)) {
> >>          return $value;
> >>      }
> >>      if (\is_string($value) && \ctype_digit($value)) {
> >>          return \intval($value);
> >>      }
> >>      throw new \InvalidArgumentException("What what!");
> >> }
> >>
> >> some_function_expecting_int(validate_int($_GET['foo'] ?? null));
> >>
> >> But the example might be erroneous, I see your point, nevertheless mak=
ing coercion explicit doesn't seem really relevant to me, the one point I l=
ike in your syntax would be null handling.
> >>
> >> --
> >>
> >> Pierre
> > Or... you could just turn off strict types instead of reinventing
> > coercion that isn't nearly as well documented as the built-in
> > coercion.
>
> That was one of my points actually.
>
> I don't see the use of a syntax such as `$foo as ?int` since all
> existing types of coercion are already possible via the cast syntax
> (please correct me if I'm wrong).
>
> In the previous message proposal, the only neat addition was the null
> handling (that's said, that's a really cool point). But cast syntax
> `(int) $foo` is really equivalent to `$foo as int` in terme of concision
> (less than 2 chars diff).

Well, $foo as int doesn't exist (yet), so there's no telling what it
will be the same as.

> In almost every case you would need coercion you also need validation,
> and validation is not something that's possible with a neat syntax, at
> least not this one, because validation is a business matter, not really
> a technical one.

That may be true, but isn't always true. Other than how it is
represented in memory, is there any difference between "123", 123, and
123.0? That's what coercion does, it makes it so that the actual
representation doesn't matter. The only thing you really have to worry
about are the edge cases (for which there are many, but that number
has slowly gone down over the years and none of the remaining ones are
truly surprising, IMHO).

And if you are just going to cast a float/string to an int anyway, you
still have edge cases (null, no warning about information loss, etc)
to handle.

> Regards,
>
> --
>
> Pierre