Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122007
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAPzBOBMw-mjjuKEX1udq2XaKGcRneT_DWinqP9aAtU0oGfLhzw@mail.gmail.com> <CAFPFaMJY=Q+vaFbhA1Xe-9xun_LPkdhL-oX2opGyV7uA_8v4Pg@mail.gmail.com>
In-Reply-To: <CAFPFaMJY=Q+vaFbhA1Xe-9xun_LPkdhL-oX2opGyV7uA_8v4Pg@mail.gmail.com>
Date: Fri, 15 Dec 2023 09:14:11 +0100
Message-ID: <CAPzBOBMVViMjZk2d0J77Ck7qktCbMnN1BpDogx=u40=gbYR7ZA@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Alexander Pravdin <alex.pravdin@interi.co>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
From: landers.robert@gmail.com (Robert Landers)

On Fri, Dec 15, 2023 at 2:10=E2=80=AFAM G. P. B. <george.banyard@gmail.com>=
 wrote:
>
> On Tue, 12 Dec 2023 at 21:00, Robert Landers <landers.robert@gmail.com> w=
rote:
>>
>> On Tue, Dec 12, 2023 at 2:04=E2=80=AFPM G. P. B. <george.banyard@gmail.c=
om> wrote:
>> > GMP supports operator overloading
>>
>> GMP kinda-sorta-most-of-the-time supports operator overloading.
>> Sometimes ... it doesn't. I implemented a field library in PHP (for
>> work a couple of years ago) and occasionally, overloading would cast
>> things back to float/int and break the math. I don't have access to
>> that code, so I don't have any examples readily available (and the
>> fact that an extension can do overloading but we can't in user-land is
>> a whole different can of worms which made this library ridiculously
>> hard to work with -- we rewrote everything in Scala and never looked
>> back). Needless to say, if I were to go into a project that required
>> GMP, I wouldn't trust the overloading.

Hey Gina,

> I have no idea how _this_ is possible considering GMP will happily throw =
type errors left and right even in cases when it shouldn't.
> If you encountered this, you should have submitted a bug report.
> Because, using a potential bug as an excuse for not doing this is... weir=
d?

The issue should have been reproducible on a smaller scale, but it
wasn't, thereby hinting that we were hitting some extremely rare edge
case that may not be easily testable. The fact that we hit it,
couldn't create a simple reproduction for reporting a bug, and you
should, theoretically, be able to rely on your software to compute
math correctly made that one person's argument: "Why don't we rewrite
this in X?" that much more persuasive...

> I have come around userland operator overloading with the proposal from J=
ordan, but considering this hasn't passed it might take a while before some=
one gives it a crack at it again.
> And it has _always_ been a thing that the engine, and internal extensions=
, can do more things than userland.
> Especially nonsensical stuff like variadic parameters not at the end...

Considering operator overloading has been declined twice (in 2021:
https://wiki.php.net/rfc/user_defined_operator_overloads, and 2020
https://wiki.php.net/rfc/userspace_operator_overloading) for "reasons"
has me thinking it probably won't be proposed again. With comments
like:

> it is not your implementation proposal,
> but rather the concept per-se that IMO shouldn't land in the language

nobody will likely ever try this again, at least in the foreseeable
future. With comments like that, there is simply no way forward.
There's no convincing (at least via email) and by that point, it's too
late anyway, they already voted but didn't even show up for the
discussion that happened for weeks. Literally wasting everyone's time.
The only way we'd ever get something like this passed is if someone
proposes an RFC that prevents people from voting based on
political/personal reasons and restricts voting "no" to technical
reasons only; or some voters reopen one of the original RFC's for a
revote and leave it in the "Pending Implementation" section as needing
an implementation.

The fact that people can and do vote "no" for no other reason than
they "don't like it" or they "don't want to use it" leaves a bad taste
in my mouth.

Robert Landers
Software Engineer
Utrecht NL