dmd 2.065.0

Jacob Carlborg doob at me.com
Tue Feb 25 12:12:41 PST 2014


On 2014-02-25 20:49, Steven Schveighoffer wrote:

> I just wrote this and compiled on 2.064:
>
> import std.stdio;
>
> struct S
> {
>      int x;
>      int y;
>      bool opEquals(ref const(S) other) const { return other.x == x;}
> }
>
> void main()
> {
>      int[S] aa;
>      aa[S(1, 2)] = 5;
>      aa[S(1, 3)] = 6;
>      writeln(aa);
> }
>
> Output:
>
> [S(1, 2):5, S(1, 3):6]
>
> Now, clearly this is not correct, and should be flagged by the compiler,
> or fixed in the runtime.
>
> I suggest this path:
>
> 1. Switch AA to using the 'equals' function
> 2. Do not allow keys that provide opCmp function but not opEquals (these
> will not work correctly)
>
> This will provide a sane implementation and not break existing code when
> the default opEquals and opCmp are used (both will act the same as far
> as AAs are concerned).

The thing is that the compiler complains about a deceleration looking 
like this:

struct TagIndex
{
     uint tag, index;
}

Neither opEquals or opCmp is overloaded. A simple test case will also 
show that the compiler doesn't not complain about a missing opCmp. I 
have not been able to create a reduced test case for this.

-- 
/Jacob Carlborg


More information about the Digitalmars-d-announce mailing list