The following code compiles with 2.062 but not with 2.063:
-------------------------------------------------------
import std.typetuple;
struct Cube
{
alias Address = TypeTuple!(int, int);
//alias Address = int;
int* opBinaryRight(string op)(Address where)
{
return null;
}
}
void main()
{
Cube cube;
cube.Address addr;
auto ptr = addr in cube;
}
---------------------------------------------------------
In 2.063, DMD produces the following:
cube.d(18): Error: rvalue of in expression must be an associative array, not Cube
Flipping the comments on the two "alias Address" lines causes the sample to compile under both, so the problem is triggered by the use of a tuple as the left side of the "in" operator. Using DMD with -v indicates the trouble is during the semantic3 phase.
Comment #1 by andrej.mitrovich — 2013-06-17T15:52:18Z
You could use Tuple from std.typecons instead and it will work.
It seems to me what's going on is auto-expansion of a TypeTuple into two arguments, and opBinaryRight (or opIn_r) simply can't accept more than one argument.
I don't know why that even worked before, it might have been an accepts-invalid bug in 2.062 and earlier. Kenji Hara will probably know more.
Comment #2 by justin — 2013-06-17T16:08:36Z
(In reply to comment #1)
> You could use Tuple from std.typecons instead and it will work.
>
> It seems to me what's going on is auto-expansion of a TypeTuple into two
> arguments, and opBinaryRight (or opIn_r) simply can't accept more than one
> argument.
>
> I don't know why that even worked before, it might have been an accepts-invalid
> bug in 2.062 and earlier. Kenji Hara will probably know more.
From my perspective it'd be somewhat unfortunate to lose the ability to do this. We make extensive use of "in" as a complement to indexing the same way associative arrays do: indexing returns the thing or throws if not present while "in" returns a pointer to the thing or null if not present. Because we use indexing with multiple "keys" it's nice to have a symmetric way of using "in".
As for your suggestion to use Tuple, we usually provide an overload for that as well, particularly because tuples can't be returned from functions.
Comment #3 by justin — 2013-07-15T15:45:23Z
An update on this issue: we have worked around this by switching away from "in" to a method-based approach, so this is no longer blocking for the reporter. I think this issue remains valid until it's decided whether the "in" operator (or operators in general) will allow a tuple on the left hand side. Here's a simplified example that matches with our use case:
-----------------------------
struct Graph(T, Address...)
{
struct Node
{
Address address;
T payload;
}
...
Node* opBinaryRight(string op)(Address address) if (op == "in)
{
...
}
}
void main()
{
Graph!(double, int, string) graph;
auto node = ...procure a node from somwhere...
// node.address is preferred to tuple(node.address)
if (auto inGraph = node.address in graph)
{
...
}
}
-----------------------------
As I said, we have worked around this because it's not unreasonable for binary operators to only allow one value on each side, but it was also nice to have this kind of syntax in 2.062 and previous.
Comment #4 by k.hara.pg — 2013-08-25T17:27:52Z
https://github.com/D-Programming-Language/dmd/pull/2497
I still have a doubt that this should be fixed... Even if the dmd implementation will be fixed in 2.064 release, we should continue discussion about the combination of operator-overloading and built-in tuple behavior.
Comment #5 by github-bugzilla — 2013-08-27T00:13:20Z