Rationale:
When writing an operator, one might accidentally typo, use the wrong signature, use the wrong name, use an un-existing name etc. Because the compiler relies on only checking function names, the end user has no way to check if the code is correct, appart from "noticing" that calling the operator doesn't work.
This can become quite clumsy once the more complicated things, like "opIndexOpAssign" (or was that "opOpIndexAssign" ?) get involved.
Description:
When writing a function with a "magic" name, one can prefix it with the keyword operator. If that function name doesn't match any of the special functions, with the correct amount of arguments, then a compile error is thrown:
//----
struct S
{
operator opBinary(string op)(S rhs); //Fine
operator opBinary(string op)(S rhs1, S rhs2); //Error, wrong number of arguments
operator opOpBinary(string op)(Type rhs); //Error, did you mean opOpAssign?
operator opcmp(Type rhs); //Error, did you mean opCmp?
static bool opEquals(S s1, S s2); //Error, opEquals cannot be declared as static
}
//----
This would help with keeping in line with D's safety standard, in particular, the override keyword.
(from the discussion: http://forum.dlang.org/thread/[email protected])
Also want to point out: This bug has even made it into phobos.
Comment #1 by bearophile_hugs — 2013-01-02T09:41:47Z
(In reply to comment #0)
> operator opBinary(string op)(S rhs); //Fine
> operator opBinary(string op)(S rhs1, S rhs2); //Error, wrong number of
> arguments
> operator opOpBinary(string op)(Type rhs); //Error, did you mean opOpAssign?
> operator opcmp(Type rhs); //Error, did you mean opCmp?
> static bool opEquals(S s1, S s2); //Error, opEquals cannot be declared as
> static
> }
> //----
>
> This would help with keeping in line with D's safety standard, in particular,
> the override keyword.
>
> (from the discussion:
> http://forum.dlang.org/thread/[email protected])
Thank you for opening a ER. I was too much busy to do it.
I don't know if the solution proposed here is the right one, but being aware that a problem exists is the first step toward its solution.
Probably a pseudo-keyword like "@operator" is more reasonable than "operator".
> Also want to point out: This bug has even made it into phobos.
I suggest to show here some of the lines of code that contain that bug.
Comment #2 by monarchdodra — 2013-01-02T09:52:39Z
(In reply to comment #1)
> > Also want to point out: This bug has even made it into phobos.
>
> I suggest to show here some of the lines of code that contain that bug.
I've since fixed it:
https://github.com/D-Programming-Language/phobos/commit/69d3a930b9d448d24b061ffc60d252ca056cb33e#L0R1805
It was really "just" a typo: "opOpassign" instead of "opOpAssign".
But still, the language shouldn't allow for "just a typo" kind of errors.
Comment #3 by schuetzm — 2014-02-07T01:33:39Z
(In reply to comment #1)
> I don't know if the solution proposed here is the right one, but being aware
> that a problem exists is the first step toward its solution.
>
> Probably a pseudo-keyword like "@operator" is more reasonable than "operator".
An alternative would be to make all methods string with op and then a capital letter (i.e. /^op[A-Z]/) reserved.
Comment #4 by schuetzm — 2014-02-07T01:34:49Z
(In reply to comment #3)
> (In reply to comment #1)
> > I don't know if the solution proposed here is the right one, but being aware
> > that a problem exists is the first step toward its solution.
> >
> > Probably a pseudo-keyword like "@operator" is more reasonable than "operator".
>
> An alternative would be to make all methods string with op and then a capital
> letter (i.e. /^op[A-Z]/) reserved.
That should be _starting_, of course.
Comment #5 by robert.schadek — 2024-12-13T18:03:34Z