Thread overview
[Issue 20399] opIn deprecation warning should point to where opIn is defined, not where it is used.
Nov 19, 2019
RazvanN
Nov 28, 2019
RazvanN
Jan 07, 2020
Simen Kjaeraas
[Issue 20399] opIn deprecation warning should point to where opIn is defined, in addition to where it is used
Dec 17, 2022
Iain Buclaw
November 19, 2019
https://issues.dlang.org/show_bug.cgi?id=20399

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
This seems to be done on purpose, although I can't figure out the reason (except for ease of implementation).

--
November 28, 2019
https://issues.dlang.org/show_bug.cgi?id=20399

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
I am tempted to close this as WONTFIX since soon we will drop the deprecation and issue an error anyway.

--
January 06, 2020
https://issues.dlang.org/show_bug.cgi?id=20399

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |schveiguy@yahoo.com
         Resolution|---                         |INVALID

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
This should be INVALID. Defining a function named opIn is not a deprecation. This produces no deprecation warning:

struct S
{
  void opIn(int x) {}
}

void main()
{
   S s;
   s.opIn(5);
}

The deprecation is using that to define operator overloading. So it is pointing at the correct location. The message may be awkward, but the location is correct.

--
January 07, 2020
https://issues.dlang.org/show_bug.cgi?id=20399

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |simen.kjaras@gmail.com
         Resolution|INVALID                     |---

--- Comment #4 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
You should only get the error if opIn is being used for operator overloading, yes.

However, the error message should at the very least mention the location where opIn is defined, as that's where the code change will need to happen. We can expect that if someone tries to use opIn with operator overloading, opIn has been written with that in mind.

Now, that means the error message should be fixed, such that this program

struct S {
    void opIn(S s) { }
}

unittest {
    S s1, s2;
    s1 in s2;
}

gives this error message:

foo.d(7) Deprecation: using opIn for operator overloading is deprecated. Call
it as s1.opIn(s2) instead, or change the definition to opBinary(string op)(...)
if (op == "in").
foo.d(2) opIn is defined here

--
January 07, 2020
https://issues.dlang.org/show_bug.cgi?id=20399

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
           Hardware|x86_64                      |All
            Summary|opIn deprecation warning    |opIn deprecation warning
                   |should point to where opIn  |should point to where opIn
                   |is defined, not where it is |is defined, in addition to
                   |used.                       |where it is used
                 OS|Linux                       |All

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Yes, that does look better. Changing fields appropriately.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=20399

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--