The message:
Deprecation: opIn is deprecated. Use opBinary(string op)(...) if (op == "in") instead.
is not really actionable at the place where "in" is used.
Comment #1 by razvan.nitu1305 — 2019-11-19T12:32:33Z
This seems to be done on purpose, although I can't figure out the reason (except for ease of implementation).
Comment #2 by razvan.nitu1305 — 2019-11-28T13:13:14Z
I am tempted to close this as WONTFIX since soon we will drop the deprecation and issue an error anyway.
Comment #3 by schveiguy — 2020-01-06T19:35:12Z
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.
Comment #4 by simen.kjaras — 2020-01-07T08:07:58Z
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
Comment #5 by schveiguy — 2020-01-07T16:40:59Z
Yes, that does look better. Changing fields appropriately.
Comment #6 by robert.schadek — 2024-12-13T19:06:14Z