I couldn't find a better title, sorry.


But yeah, I've spent too many hours on hunting down problems like these...


Could someone explain what's going on? Thanks!

import std.stdio;
struct S { int[int] aa; }
void main()
{
	writeln(  [1: 2]  ==   [1: 2] );  // true
	writeln(S([1: 2]) == S([1: 2]));  // false
}

(I'm on Windows DMD v2.060.)

On 10/24/2012 09:17 PM, Mehrdad wrote:
> I couldn't find a better title, sorry.
>
>
> But yeah, I've spent too many hours on hunting down problems like these...
>
>
> Could someone explain what's going on? Thanks!
>
> import std.stdio;
> struct S { int[int] aa; }
> void main()
> {
>      writeln(  [1: 2]  ==   [1: 2] );  // true
>      writeln(S([1: 2]) == S([1: 2]));  // false
> }
>
> (I'm on Windows DMD v2.060.)

http://d.puremagic.com/issues/show_bug.cgi?id=3789

On 10/24/12, Mehrdad <wfunction@hotmail.com> wrote:
> Could someone explain what's going on? Thanks!

Struct fields are compared by address by default if no opEquals is defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789

On Wednesday, 24 October 2012 at 19:25:47 UTC, Timon Gehr wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=3789


Ouch, bug since 2010...
(Thanks for the link.)

On 10/24/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> On 10/24/12, Mehrdad <wfunction@hotmail.com> wrote:
>> Could someone explain what's going on? Thanks!
>
> Struct fields are compared by address by default if no opEquals is defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789
>

Well I mean for reference types. Or something like that. To put it bluntly: It's brokeeen.

On Wednesday, 24 October 2012 at 19:28:36 UTC, Andrej Mitrovic wrote:
> On 10/24/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> On 10/24/12, Mehrdad <wfunction@hotmail.com> wrote:
>>> Could someone explain what's going on? Thanks!
>>
>> Struct fields are compared by address by default if no opEquals is
>> defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789
>>
>
> Well I mean for reference types. Or something like that. To put it bluntly: It's brokeeen.


Yeah, and my attempts to get around it don't seem to help:

	auto a = [1:1], b = [1:1];
	writeln(a == b);       // true
	writeln(a in [a:0]);   // null

On Wed, Oct 24, 2012 at 09:17:09PM +0200, Mehrdad wrote: [...]
> Could someone explain what's going on? Thanks!
> 
> import std.stdio;
> struct S { int[int] aa; }
> void main()
> {
> 	writeln(  [1: 2]  ==   [1: 2] );  // true
> 	writeln(S([1: 2]) == S([1: 2]));  // false
> }
[...]

I don't know if there is any struct-specific problem here, but AA comparison right now is horribly horribly broken (search on the bug tracker for "AA" and you'll see a bunch of issues on that end). You're incredibly lucky that two AA literals actually compared equal. In some cases, not even that is guaranteed.

I've tried to clean up the AA code but it's a tangled messy ugly labyrinth with fragile hacks sprinkled in, and didn't get to the point where it's ready to commit. One major obstacle is that parts of it are implemented in compiler hacks, and part of it is schizophrenically duplicated in object_.d, not necessarily consistently, and it's just Not Nice in general. That it works at all is reason enough to be thankful. I don't expect things to be pretty once you start poking into the intricacies of AA's, sad to say.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Wednesday, 24 October 2012 at 19:32:08 UTC, Mehrdad wrote:
> Yeah, and my attempts to get around it don't seem to help:
>
> 	auto a = [1:1], b = [1:1];
> 	writeln(a == b);       // true
> 	writeln(a in [a:0]);   // null


Harsh (but true, and perhaps useful) feedback...
I feel like this is a *perfect* example of the kinds of things that turn people off of D.

I don't know what to expect code like this to do (unlike in C++, where everything is clearly defined in the specs), and when it seems to do what I want, it really turns out to be a bug in the library that it seemed to work in the first place. :(

On Wednesday, 24 October 2012 at 19:34:15 UTC, H. S. Teoh wrote:
> I don't know if there is any struct-specific problem here, but AA comparison right now is horribly horribly broken (search on the bug tracker for "AA" and you'll see a bunch of issues on that end). You're incredibly lucky that two AA literals actually compared equal. In some cases, not even that is guaranteed.


Yeah, I was a little aware that AAs were semi-broken, but I thought, hey, if it seems to work then it obviously works.
Turns out that wasn't so true. :\



> I've tried to clean up the AA code but it's a tangled messy ugly labyrinth with fragile hacks sprinkled in, and didn't get to the point where it's ready to commit. One major obstacle is that parts of it are implemented in compiler hacks, and part of it is schizophrenically duplicated in object_.d, not necessarily consistently, and it's just Not Nice in general. That it works at all is reason enough to be thankful. I don't expect things to be pretty once you start poking into the intricacies of AA's, sad to say.



Yeah, the trouble is, none of the set-based data types (including maps) in D seem to be working...

- AAs are broken
- AssociativeArray is the same as above, I think?
- RedBlackTree is useless (how do I keep a "set of sets"?)
etc.


So you can't really write a real program in D, to put it blunty.

On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
> So you can't really write a real program in D, to put it bluntly.


Case in point: there's no way to tell an arbitrary object/struct to give you its hash code.