Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125591
Precedence: bulk
MIME-Version: 1.0
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <F2492D64-797D-4195-A996-AF1F7C758674@gmail.com> <18603813-9ECB-4486-95EE-08BEDECAB88D@newclarity.net>
 <CAMrTa2HzaSssZYJ6PrWkKDfsGVWyTq0_aB5xGKTS=Nb8GHiOug@mail.gmail.com> <F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net>
In-Reply-To: <F6B400AE-A092-43F2-BB1A-B3A5EB0EBD4B@newclarity.net>
Date: Tue, 17 Sep 2024 10:22:12 -0700
Message-ID: <CAMrTa2EoaGrupTuCkO-AMoueJfYqPECnvjWgXNRKHQF8_nLV4g@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cc976a062253eed3"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000cc976a062253eed3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 17, 2024 at 2:14=E2=80=AFAM Mike Schinkel <mike@newclarity.net>=
 wrote:

> > On Sep 17, 2024, at 1:37 AM, Jordan LeDoux <jordan.ledoux@gmail.com>
> wrote:
> > On Mon, Sep 16, 2024 at 9:35=E2=80=AFPM Mike Schinkel <mike@newclarity.=
net>
> wrote:
> >
> > Yes, if constraints of the nature I propose below are adopted.
> >
> > The biggest problem I have with operator overloads is that =E2=80=94 on=
ce added
> =E2=80=94 all code could potentially be "infected" with operator overload=
s.
> However, if the developer *using* an operator overload could instead opt-=
in
> to using them, in context, then I would flip my opinion and I would begin
> to support them.
> >
> > What might opt-in look like?  I propose two (2) mechanisms of which eac=
h
> would be useful for different use-cases. As such I do not see these two a=
s
> competing but instead would expect adding both to be preferable:
> >
> > 1. Add a pair of sigils to enclose any expression that would need to
> support userland operator overloading. This would allow a developer to
> isolate just the expression that needs to use operator overloading. I
> propose {[...]} for this, but feel free to bikeshed sigils. Using an
> example from the RFC, here is what code might look like:
> >
> > $cnum1 =3D new ComplexNumber(1, 2);
> > $cnum2 =3D new ComplexNumber(3, 4);
> > $cnum3 =3D {[ $cnum1 * $cnum2 ]};               // Uses operator
> operloading sigils
> > echo $cnum3->realPart.' + '.$cnum3->imaginaryPart.'i';
> >
> > 2. For when using `{[...]}` would be annoying because it would be neede=
d
> in so many places, PHP could also add support for an attribute. e.g.
> `#[OperatorOverloads(Userland:true)]`. This attribute would apply to
> functions, methods, classes, enums, (other?) and indicates that operator
> overloads can be present anywhere in the body of the decorated structure.=
 I
> included `Userland:true` as an indicator to a reader that this only appli=
es
> to userland operator overloads and that built-in ones like in GMP and
> anywhere else would not need to be opted into, but that parameter could o=
f
> course be dropped if others feel it is not needed. Again, feel free to
> bikeshed attribute name and/or parameters.
> >
> > #[OperatorOverloads(Userland:true)]
> > function SprintProductOfTwoComplex(ComplexNumber $cnum1, ComplexNumber
> $cnum2)string {
> >   $cnum3 =3D $cnum1 * $cnum2;
> >   return sprintf("%d + %di", $cnum3->realPart, $cnum3->imaginaryPart);
> > }
> >
> > If this approach were included in the RFC then it would also ensure
> there is no possibility of BC breakage. BC breakage which would certainly
> be an edge case but I can envision it would be possible,e specially where
> newer instances incorporating operator overloads are passed to functions
> that did not have parameters type hinted but were not intend to be used
> with operator overloads resulting in subtle potential breakage.
> >
> > This argument is also consistent with the argument people had about not
> allowing default values to be generically used in calls to the function
> function. Their claim was that developers who did not write their code wi=
th
> the intention of exposing defaults should not have their defaults exposed=
.
> Similarly developers that do not write their code to enable operator
> overloads should not be used with  userland operator overloads unless the=
y
> explicitly allow it, especially as they may not have have tested code wit=
h
> operator overloads.
> >
> > Anyway, that is my two cents worth.
> >
> > TL;DR?  I argue that PHP should operator overloads but ONLY if there is
> a mechanism that requires the user of expressions that call overloaded
> operators to explicitly opt-in to their use.
> >
> > -Mike
> >
> >
> > This is interesting, as I've never seen this in any language I
> researched as part of operator overloading, and also was never given this
> feedback or anything similar by anyone who provided feedback before.
>
> If all language features required prior art, there would never be
> innovation in programming languages. So for anything that currently exist=
s,
> there was always a first language that implemented it.
>
> Of course when there is prior art we can use the heuristic of "All these
> have done it before so it must be a good idea."  But lack of prior art
> should not be the reason to dismiss something, it should be evaluated on
> its merits.
>
> > My initial reaction is that I do not understand how this is any better
> than parameter typing. If you do not allow any objects into the scope you
> are using operators, wouldn't that be the same as the kind of userland
> control you are after? Or rather, how would it be substantially worse?
>
> How would a developer know if they are using an object that has operators=
,
> unless they study all the source code or at least the docs (assuming ther=
e
> are good docs, which there probably are not?)
>
> It might be illustrative to explicitly call out different scenarios I
> envision in case some are not obvious.
>
> There are:
>
> 1. Internal projects that are almost entirely bespoke code, with an activ=
e
> team where the code is run by the code owners. Think a big company's
> internal operations.
>
> 2. Agencies that build web projects using frameworks and libraries for
> clients.
>
> 3. Smaller companies using frameworks and libraries for internal use, wit=
h
> a small team that may have many other duties, or those who outsource to
> contractors when they need things, and breakage for them is can be very
> painful.
>
> 4. Framework developers
>
> 5. Library developers
>
> 6. And probably a bunch of other scenarios, each slightly different.
>
> Each of those scenarios have a different level of knowledge about the cod=
e
> they work on. I'd expect #2 & #3 to have the least knowledge of the code
> they use and would be most effected by other people's code doing things
> they do not expect.
>
> I'd argue that #1 would have better knowledge of their code and would be
> less affected by other people's code, except they probably have a huge
> amount of bespoke code so one developer likely does not know what another
> developer is doing, and especially if they have teams that developer tool=
s
> for other teams to use.
>
> Lastly #4 and #5 likely know their codebases the best, but they may creat=
e
> footguns for developers in category #2 and #3 if the language allows them
> to. And vice-versa.
>
> So back to your question "If you do not allow any objects into the scope
> you are using operators wouldn't that be the same as the kind of userland
> control you are after?" So I ask =E2=80=94 How do I know if the objects I=
 am using
> that were developed by others use operators or not? With free-reign
> userland operator overloads we would be required to dig into the source f=
or
> the code written by others that we use to ensure I know if they have
> operators and how they work.
>
> OTOH with my suggestion, we will know because the code will crash when no
> opt-in is used.
>
> Note, I refer to cases where code that calls code evolves, uses dynamic
> programming, and/or accepts mixed types. And I am especially talking abou=
t
> when developers create classes to wrap a built-in type and then implement
> operators, but add special cases to them such as a String() class that
> implements the concatenation operator but with a twist.
>
> > Your second example even includes a function that only accepts a
> `ComplexNumber` object. I presume in your example there that if the
> Attribute was removed, the function would just always produce a fatal
> error, since that is the behavior of objects when used with `*`.
>
> Yes, that was the intention for the attribute, or lack of attribute in th=
e
> case you describe.
>
> >
> > What it appears to me your proposal does is transform working operator
> overloads into fatal errors if the user-code does not "opt-in".
>
> Correct.
>
> > But any such code would never actually survive long, wouldn't it?
>
> That is the feature, not a bug.
>
> > Without the opt-in, these objects would ALWAYS produce fatal errors
> (which is what happens now),
>
> Well, we do not have operator overloads right now. With operator overload=
s
> they could run without crashing but have subtle bugs.
>
> Note I am not referring to highly specific functions written for highly
> specific classes which is what I suspect you are envisioning. Based on yo=
ur
> past comments those seem to be the areas you operate in, i.e. math-relate=
d.
>
> I am instead referring to code that is written to be generic but that end=
s
> up running code it did not intend to run because of edge cases that are
> exposed by userland operators.
>
> > which would eventually show up in testing, QA, etc.
>
> Eventually.  Assuming they have a good testing and QA process which many
> PHP projects do not. PHP is a least-common denominator language because i=
t
> is one of the easiest to get started with. Many less experienced PHP
> developers do not have good testing and QA processes.
>
> But even if they do have good testing and QA, the sooner the bugs appear
> the less likely they will get deployed.
>
> > The developer would realize that they (presumably) were trying to do a
> math operation on something they thought was only a numeric type, and the=
n
> guard against objects being passed into that context with control
> statements, parameter types, etc.
>
> Exactly. In my proposed concept they would rework their expressions to
> opt-in to using the overloaded operators once they ensure that they
> understand how the code operates.
>
> > So it seems to me what this ACTUALLY guards against is developers who
> inadvertently don't type-check their variables in code where the specific
> type is relevant.
>
> OR do not fully know the details of the types they are using.
>
> OR they are using types that have been upgraded to now support operator
> overloading, but they do not realize that.
>
> > After one round of testing, all of the code using operators would eithe=
r
> always allow objects and thus overloads, or never allow objects and thus
> not use overloads.
>
> That assumes they crash. I am concerned for when they do not crash but
> instead have subtle bugs.
>
> > There shouldn't even be any existing code that would be affected, since
> any existing code would need to currently allow objects in a context wher=
e
> operators are used, which currently produces a fatal error 100% of the
> time, (excepting internal classes which are mostly final anyway, and thus
> unaffected by this proposal).
>
> It is correct that no old code can call other old code and use operators
> on objects.
>
> But *new* code could call old code and then that old code could be made t=
o
> run operators without ever intending to be run in that manner.
>
> > What is the situation where your suggestion is implemented, a developer
> does NOT opt-in to overloads, and they avoid unexpected behavior without
> having to change their existing code to fix fatal errors? I don't see how
> that is possible.
>
> In your hypothetical it appears you referred to only one developer. But
> where I see issues is when there are two or more developers; a producer o=
f
> functions and a consumer of functions.
>
> Situation where there is free-reign userland operator overloading:  Junio=
r
> developer Joe is using Symfony and learns about this great new operator
> overload feature so decides to implement all the operators for all his
> objects, and now he wants to start passing his objects to Symphony code.
> Joe decides to be clever and implement "/" to concatenate paths strings
> together but doesn't type his properties, and he ends up passing them to =
a
> Symfony function that uses `/` for division, and his program crashes with
> very cryptic error messages.  He reports them to the Symfony developers,
> and it wastes a bunch of time for everyone until they finally figure out
> why it failed, because nobody every considered a developer would do such =
a
> thing.
>
> Same scenario but with required opt-in. Joe does the same thing but this
> time he gets a very clear message that says "Symfony Widget does not
> support operator overloads."  He googles and quickly finds out that what
> that means and then goes to ask the Symfony team to support operator
> overloads. They can choose to either add support, or not, but it is up to
> them if they want to open the can of worms related to support that operat=
or
> overloading might cause.
>
> > Also, replying into a 3 year old reddit thread I linked to for referenc=
e
> is not what I intended, however I want to highlight one other thing you
> commented there but not here for some reason:
> >
> > > To illustrate my point, imagine if we also allowed control structure
> overloads. If we had them we could no longer read code and know that an
> `if` is a branch and a `for` is a loop; either could be anything valid fo=
r
> any control structure. Talk about ambiguity!
> >
> > Indeed. I want to make sure that I have not been ambiguous after readin=
g
> this, because I found it somewhat troubling:
> >
> > I am looking at writing an RFC for specific *operators* that are finite
> and defined within the RFC. I am not proposing something that would allow
> control structures to be altered (I don't even think that would be possib=
le
> without essentially rewriting the entire Zend Engine specifically to do i=
t).
> >
> > Operators are not control structures. Operators mutate the value or
> state of a variable in a repeatable way, given the input states. There is
> not even a generalized mechanism in my RFC for "arbitrary" overloads, and
> the compiler was not implemented in a way that is generalized for it
> either. It allows only exactly the operators that are part of the RFC, an=
d
> each are handled specifically and individually.
>
> I was ONLY using control structures as a more extreme analogy to operator
> overloading to try to illustrate how =E2=80=94 the more things you make
> configurable in a language =E2=80=94 the more you allow the ground to shi=
ft beneath
> a developer's feet, so to speak.
>
> An approach I use when trying to understand something that might be subtl=
e
> is to ask myself what a more extreme example is that would be analogous a=
nd
> then I consider that.
>
> So I was not saying you proposed that, I was equating control structure
> overloading to operator overloading, but I explicitly meant control
> structure overloading would be a more extreme opening up of PHP than
> operator overloading.
>
> Clearly control structure overloading would be bad. I was trying to make
> the point that operator overloading would cause problems for the same
> reason, even if the problems would not be as extreme.
>
> I am sorry that my wording did not make it clear that I was using an
> analogy, not referring to your RFC.
>
> Anyway, as a closing for this email, I know you badly want operator
> overloading but there were enough people who disliked the idea to vote
> against it last time so =E2=80=94 assuming my proposal could satisfy them=
 too =E2=80=94 it
> seems like a great compromise to give you true operator overloading with
> just a little extra boilerplate while at the same time allowing developer=
s
> to limit the scope of operator overloads to just those function where the=
y
> want to enable it.
>
> What's more, if after a few years we find out that my concerns really wer=
e
> for naught then a future RFC could open it up and remove the opt-in
> requirement.
>
> But one thing is certain, if we open up operator overloading completely
> one day one we could never go back to opt-in.
>
> -Mike


While I do not presume to speak for all voters (I don't even have voting
rights myself), my feeling from all of the conversations I have had over
almost the last 4 years is that implementing your suggestion would
virtually guarantee that the RFC is declined. You are suggesting providing
a new syntax (which voters tend to be skeptical of) to create a situation
where more errors occur (which voters tend to be skeptical of) to solve a
problem which can be solved with existing syntax by simply type guarding
your code to not allow any objects near your operators (which voters tend
to be skeptical of) for which I cannot find any code examples that explain
the problem it is solving (which voters tend to skeptical of).

Jordan

--000000000000cc976a062253eed3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 17, 2024 at 2:14=E2=80=AF=
AM Mike Schinkel &lt;<a href=3D"mailto:mike@newclarity.net">mike@newclarity=
.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">&gt; On Sep 17, 2024, at 1:37 AM, Jordan LeDoux &lt;<a href=3D"mailto:j=
ordan.ledoux@gmail.com" target=3D"_blank">jordan.ledoux@gmail.com</a>&gt; w=
rote:<br>
&gt; On Mon, Sep 16, 2024 at 9:35=E2=80=AFPM Mike Schinkel &lt;<a href=3D"m=
ailto:mike@newclarity.net" target=3D"_blank">mike@newclarity.net</a>&gt; wr=
ote:<br>
&gt; <br>
&gt; Yes, if constraints of the nature I propose below are adopted.<br>
&gt; <br>
&gt; The biggest problem I have with operator overloads is that =E2=80=94 o=
nce added =E2=80=94 all code could potentially be &quot;infected&quot; with=
 operator overloads. However, if the developer *using* an operator overload=
 could instead opt-in to using them, in context, then I would flip my opini=
on and I would begin to support them.=C2=A0 <br>
&gt; <br>
&gt; What might opt-in look like?=C2=A0 I propose two (2) mechanisms of whi=
ch each would be useful for different use-cases. As such I do not see these=
 two as competing but instead would expect adding both to be preferable:<br=
>
&gt; <br>
&gt; 1. Add a pair of sigils to enclose any expression that would need to s=
upport userland operator overloading. This would allow a developer to isola=
te just the expression that needs to use operator overloading. I propose {[=
...]} for this, but feel free to bikeshed sigils. Using an example from the=
 RFC, here is what code might look like:<br>
&gt; <br>
&gt; $cnum1 =3D new ComplexNumber(1, 2);<br>
&gt; $cnum2 =3D new ComplexNumber(3, 4);<br>
&gt; $cnum3 =3D {[ $cnum1 * $cnum2 ]};=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// Uses operator operloading sigils<br>
&gt; echo $cnum3-&gt;realPart.&#39; + &#39;.$cnum3-&gt;imaginaryPart.&#39;i=
&#39;;<br>
&gt; <br>
&gt; 2. For when using `{[...]}` would be annoying because it would be need=
ed in so many places, PHP could also add support for an attribute. e.g. `#[=
OperatorOverloads(Userland:true)]`. This attribute would apply to functions=
, methods, classes, enums, (other?) and indicates that operator overloads c=
an be present anywhere in the body of the decorated structure. I included `=
Userland:true` as an indicator to a reader that this only applies to userla=
nd operator overloads and that built-in ones like in GMP and anywhere else =
would not need to be opted into, but that parameter could of course be drop=
ped if others feel it is not needed. Again, feel free to bikeshed attribute=
 name and/or parameters.<br>
&gt; <br>
&gt; #[OperatorOverloads(Userland:true)]<br>
&gt; function SprintProductOfTwoComplex(ComplexNumber $cnum1, ComplexNumber=
 $cnum2)string {<br>
&gt;=C2=A0 =C2=A0$cnum3 =3D $cnum1 * $cnum2;<br>
&gt;=C2=A0 =C2=A0return sprintf(&quot;%d + %di&quot;, $cnum3-&gt;realPart, =
$cnum3-&gt;imaginaryPart);<br>
&gt; }<br>
&gt; <br>
&gt; If this approach were included in the RFC then it would also ensure th=
ere is no possibility of BC breakage. BC breakage which would certainly be =
an edge case but I can envision it would be possible,e specially where newe=
r instances incorporating operator overloads are passed to functions that d=
id not have parameters type hinted but were not intend to be used with oper=
ator overloads resulting in subtle potential breakage. <br>
&gt; <br>
&gt; This argument is also consistent with the argument people had about no=
t allowing default values to be generically used in calls to the function f=
unction. Their claim was that developers who did not write their code with =
the intention of exposing defaults should not have their defaults exposed. =
Similarly developers that do not write their code to enable operator overlo=
ads should not be used with=C2=A0 userland operator overloads unless they e=
xplicitly allow it, especially as they may not have have tested code with o=
perator overloads.<br>
&gt; <br>
&gt; Anyway, that is my two cents worth. <br>
&gt; <br>
&gt; TL;DR?=C2=A0 I argue that PHP should operator overloads but ONLY if th=
ere is a mechanism that requires the user of expressions that call overload=
ed operators to explicitly opt-in to their use.<br>
&gt; <br>
&gt; -Mike<br>
&gt; <br>
&gt; <br>
&gt; This is interesting, as I&#39;ve never seen this in any language I res=
earched as part of operator overloading, and also was never given this feed=
back or anything similar by anyone who provided feedback before.<br>
<br>
If all language features required prior art, there would never be innovatio=
n in programming languages. So for anything that currently exists, there wa=
s always a first language that implemented it. <br>
<br>
Of course when there is prior art we can use the heuristic of &quot;All the=
se have done it before so it must be a good idea.&quot;=C2=A0 But lack of p=
rior art should not be the reason to dismiss something, it should be evalua=
ted on its merits.<br>
<br>
&gt; My initial reaction is that I do not understand how this is any better=
 than parameter typing. If you do not allow any objects into the scope you =
are using operators, wouldn&#39;t that be the same as the kind of userland =
control you are after? Or rather, how would it be substantially worse?<br>
<br>
How would a developer know if they are using an object that has operators, =
unless they study all the source code or at least the docs (assuming there =
are good docs, which there probably are not?) <br>
<br>
It might be illustrative to explicitly call out different scenarios I envis=
ion in case some are not obvious.=C2=A0 <br>
<br>
There are:<br>
<br>
1. Internal projects that are almost entirely bespoke code, with an active =
team where the code is run by the code owners. Think a big company&#39;s in=
ternal operations.<br>
<br>
2. Agencies that build web projects using frameworks and libraries for clie=
nts.<br>
<br>
3. Smaller companies using frameworks and libraries for internal use, with =
a small team that may have many other duties, or those who outsource to con=
tractors when they need things, and breakage for them is can be very painfu=
l.<br>
<br>
4. Framework developers<br>
<br>
5. Library developers<br>
<br>
6. And probably a bunch of other scenarios, each slightly different.<br>
<br>
Each of those scenarios have a different level of knowledge about the code =
they work on. I&#39;d expect #2 &amp; #3 to have the least knowledge of the=
 code they use and would be most effected by other people&#39;s code doing =
things they do not expect.<br>
<br>
I&#39;d argue that #1 would have better knowledge of their code and would b=
e less affected by other people&#39;s code, except they probably have a hug=
e amount of bespoke code so one developer likely does not know what another=
 developer is doing, and especially if they have teams that developer tools=
 for other teams to use.<br>
<br>
Lastly #4 and #5 likely know their codebases the best, but they may create =
footguns for developers in category #2 and #3 if the language allows them t=
o. And vice-versa.<br>
<br>
So back to your question &quot;If you do not allow any objects into the sco=
pe you are using operators wouldn&#39;t that be the same as the kind of use=
rland control you are after?&quot; So I ask =E2=80=94 How do I know if the =
objects I am using that were developed by others use operators or not? With=
 free-reign userland operator overloads we would be required to dig into th=
e source for the code written by others that we use to ensure I know if the=
y have operators and how they work. <br>
<br>
OTOH with my suggestion, we will know because the code will crash when no o=
pt-in is used.<br>
<br>
Note, I refer to cases where code that calls code evolves, uses dynamic pro=
gramming, and/or accepts mixed types. And I am especially talking about whe=
n developers create classes to wrap a built-in type and then implement oper=
ators, but add special cases to them such as a String() class that implemen=
ts the concatenation operator but with a twist.<br>
<br>
&gt; Your second example even includes a function that only accepts a `Comp=
lexNumber` object. I presume in your example there that if the Attribute wa=
s removed, the function would just always produce a fatal error, since that=
 is the behavior of objects when used with `*`.<br>
<br>
Yes, that was the intention for the attribute, or lack of attribute in the =
case you describe.<br>
<br>
&gt; <br>
&gt; What it appears to me your proposal does is transform working operator=
 overloads into fatal errors if the user-code does not &quot;opt-in&quot;.<=
br>
<br>
Correct.<br>
<br>
&gt; But any such code would never actually survive long, wouldn&#39;t it?<=
br>
<br>
That is the feature, not a bug. <br>
<br>
&gt; Without the opt-in, these objects would ALWAYS produce fatal errors (w=
hich is what happens now),<br>
<br>
Well, we do not have operator overloads right now. With operator overloads =
they could run without crashing but have subtle bugs.=C2=A0 <br>
<br>
Note I am not referring to highly specific functions written for highly spe=
cific classes which is what I suspect you are envisioning. Based on your pa=
st comments those seem to be the areas you operate in, i.e. math-related. <=
br>
<br>
I am instead referring to code that is written to be generic but that ends =
up running code it did not intend to run because of edge cases that are exp=
osed by userland operators.<br>
<br>
&gt; which would eventually show up in testing, QA, etc.<br>
<br>
Eventually.=C2=A0 Assuming they have a good testing and QA process which ma=
ny PHP projects do not. PHP is a least-common denominator language because =
it is one of the easiest to get started with. Many less experienced PHP dev=
elopers do not have good testing and QA processes.<br>
<br>
But even if they do have good testing and QA, the sooner the bugs appear th=
e less likely they will get deployed.<br>
<br>
&gt; The developer would realize that they (presumably) were trying to do a=
 math operation on something they thought was only a numeric type, and then=
 guard against objects being passed into that context with control statemen=
ts, parameter types, etc.<br>
<br>
Exactly. In my proposed concept they would rework their expressions to opt-=
in to using the overloaded operators once they ensure that they understand =
how the code operates.<br>
<br>
&gt; So it seems to me what this ACTUALLY guards against is developers who =
inadvertently don&#39;t type-check their variables in code where the specif=
ic type is relevant.<br>
<br>
OR do not fully know the details of the types they are using.<br>
<br>
OR they are using types that have been upgraded to now support operator ove=
rloading, but they do not realize that.<br>
<br>
&gt; After one round of testing, all of the code using operators would eith=
er always allow objects and thus overloads, or never allow objects and thus=
 not use overloads.<br>
<br>
That assumes they crash. I am concerned for when they do not crash but inst=
ead have subtle bugs.<br>
<br>
&gt; There shouldn&#39;t even be any existing code that would be affected, =
since any existing code would need to currently allow objects in a context =
where operators are used, which currently produces a fatal error 100% of th=
e time, (excepting internal classes which are mostly final anyway, and thus=
 unaffected by this proposal).<br>
<br>
It is correct that no old code can call other old code and use operators on=
 objects.<br>
<br>
But *new* code could call old code and then that old code could be made to =
run operators without ever intending to be run in that manner.<br>
<br>
&gt; What is the situation where your suggestion is implemented, a develope=
r does NOT opt-in to overloads, and they avoid unexpected behavior without =
having to change their existing code to fix fatal errors? I don&#39;t see h=
ow that is possible.<br>
<br>
In your hypothetical it appears you referred to only one developer. But whe=
re I see issues is when there are two or more developers; a producer of fun=
ctions and a consumer of functions.<br>
<br>
Situation where there is free-reign userland operator overloading:=C2=A0 Ju=
nior developer Joe is using Symfony and learns about this great new operato=
r overload feature so decides to implement all the operators for all his ob=
jects, and now he wants to start passing his objects to Symphony code. Joe =
decides to be clever and implement &quot;/&quot; to concatenate paths strin=
gs together but doesn&#39;t type his properties, and he ends up passing the=
m to a Symfony function that uses `/` for division, and his program crashes=
 with very cryptic error messages.=C2=A0 He reports them to the Symfony dev=
elopers, and it wastes a bunch of time for everyone until they finally figu=
re out why it failed, because nobody every considered a developer would do =
such a thing.<br>
<br>
Same scenario but with required opt-in. Joe does the same thing but this ti=
me he gets a very clear message that says &quot;Symfony Widget does not sup=
port operator overloads.&quot;=C2=A0 He googles and quickly finds out that =
what that means and then goes to ask the Symfony team to support operator o=
verloads. They can choose to either add support, or not, but it is up to th=
em if they want to open the can of worms related to support that operator o=
verloading might cause.<br>
<br>
&gt; Also, replying into a 3 year old reddit thread I linked to for referen=
ce is not what I intended, however I want to highlight one other thing you =
commented there but not here for some reason:<br>
&gt; <br>
&gt; &gt; To illustrate my point, imagine if we also allowed control struct=
ure overloads. If we had them we could no longer read code and know that an=
 `if` is a branch and a `for` is a loop; either could be anything valid for=
 any control structure. Talk about ambiguity! <br>
&gt; <br>
&gt; Indeed. I want to make sure that I have not been ambiguous after readi=
ng this, because I found it somewhat troubling:<br>
&gt; <br>
&gt; I am looking at writing an RFC for specific *operators* that are finit=
e and defined within the RFC. I am not proposing something that would allow=
 control structures to be altered (I don&#39;t even think that would be pos=
sible without essentially rewriting the entire Zend Engine specifically to =
do it).<br>
&gt; <br>
&gt; Operators are not control structures. Operators mutate the value or st=
ate of a variable in a repeatable way, given the input states. There is not=
 even a generalized mechanism in my RFC for &quot;arbitrary&quot; overloads=
, and the compiler was not implemented in a way that is generalized for it =
either. It allows only exactly the operators that are part of the RFC, and =
each are handled specifically and individually.<br>
<br>
I was ONLY using control structures as a more extreme analogy to operator o=
verloading to try to illustrate how =E2=80=94 the more things you make conf=
igurable in a language =E2=80=94 the more you allow the ground to shift ben=
eath a developer&#39;s feet, so to speak.<br>
<br>
An approach I use when trying to understand something that might be subtle =
is to ask myself what a more extreme example is that would be analogous and=
 then I consider that.=C2=A0 <br>
<br>
So I was not saying you proposed that, I was equating control structure ove=
rloading to operator overloading, but I explicitly meant control structure =
overloading would be a more extreme opening up of PHP than operator overloa=
ding.=C2=A0 <br>
<br>
Clearly control structure overloading would be bad. I was trying to make th=
e point that operator overloading would cause problems for the same reason,=
 even if the problems would not be as extreme.<br>
<br>
I am sorry that my wording did not make it clear that I was using an analog=
y, not referring to your RFC.<br>
<br>
Anyway, as a closing for this email, I know you badly want operator overloa=
ding but there were enough people who disliked the idea to vote against it =
last time so =E2=80=94 assuming my proposal could satisfy them too =E2=80=
=94 it seems like a great compromise to give you true operator overloading =
with just a little extra boilerplate while at the same time allowing develo=
pers to limit the scope of operator overloads to just those function where =
they want to enable it. <br>
<br>
What&#39;s more, if after a few years we find out that my concerns really w=
ere for naught then a future RFC could open it up and remove the opt-in req=
uirement. <br>
<br>
But one thing is certain, if we open up operator overloading completely one=
 day one we could never go back to opt-in.<br>
<br>
-Mike</blockquote><div><br></div><div>While I do not presume to speak for a=
ll voters (I don&#39;t even have voting rights myself), my feeling from all=
 of the conversations I have had over almost the last 4 years is that imple=
menting your suggestion would virtually guarantee that the RFC is declined.=
 You are suggesting providing a new syntax (which voters tend to be skeptic=
al of) to create a situation where more errors occur (which voters tend to =
be skeptical of) to solve a problem which can be solved with existing synta=
x by simply type guarding your code to not allow any objects near your oper=
ators (which voters tend to be skeptical of) for which I cannot find any co=
de examples that explain the problem it is solving (which voters tend to sk=
eptical of).</div><div><br></div><div>Jordan<br></div></div></div>

--000000000000cc976a062253eed3--