On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
> You want to explain why the code is bugguy.

Sure. He didn't know the behavior of "==" on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior.

On Tuesday, 23 April 2013 at 06:07:55 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
>> I stand corrected I guess. I'll stop thinking as well.
>> ...
>> Okay sure, have fun watching people use languages that make more sense to them than D I guess.
>
> *sigh*
>
> I really wish you'd be more cooperative in this conversation.
> I certainly don't want to drive anyone away from D.
> I really don't understand why someone would say "If you don't do what I want, I'm leaving!" expecting to get their way, though.

That's not quite what I'm saying.
I'm just trying to make a point, which I'll repeat below.


> I'm trying to explain to you what's going on so that you can understand what is happening so that it will "make sense to you."


The trouble is that you've already failed before you started.


People hate C++ because it's unintuitive. I can spend all day telling you about why C++'s behavior in e.g. the Abrahams-Dimov example (look it up) is _TECHNICALLY_ the correct/expected behavior.

But in the end of the day it just doesn't make sense.
I might win the battle, but C++ has already lost the war.


So my point is, whether or not you can convince me this behavior is correct (and you probably won't), it's not going to change whether people find D easy to use.


There's a reason why no other popular language (that I know of) translates "==" into a bitwise comparison of structs. What do you think the reason might be?

On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
>
> There's a reason why no other popular language (that I know of) translates "==" into a bitwise comparison of structs. What do you think the reason might be?

I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.

On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
>>
>> There's a reason why no other popular language (that I know of) translates "==" into a bitwise comparison of structs. What do you think the reason might be?
>
> I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.

I guess C and C++ aren't even considered languages anymore.

On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
>> For fast bitwise comparison there's the "is" operator.
>> The "==" operator should be "slow".
>> See also http://d.puremagic.com/issues/show_bug.cgi?id=3789
>
> Well okay. The docs will have to be updated for this issue if it's "fixed".
>
> For instance:
> http://dlang.org/ctod.html#structcmp
>
> In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to "just work." But I suppose using "is" is more appropriate for this type of behavior. But calling it "broken" is a bit too strong.

OK let me sum this up, as you seem confused.

Whatever you think == should do, it is broken. If we assume that == should check for equality, then :
pragma(msg, S("a") == S("a".idup));
writeln(S("a") == S("a".idup));
writeln(S(+0.0) == S(-0.0));

Should all evaluate to true.

If == stand for identity, then they must all be false.

You see that whatever is the semantic of ==, it is not properly implemented right now.

Now, as we use == for equality and "is" for identity in other places (slices and objects for instance) it make sense to use the same for struct. But that another topic, as the demonstrated behavior is wrong, whatever is the semantic of ==.

On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
>>
>> There's a reason why no other popular language (that I know of) translates "==" into a bitwise comparison of structs. What do you think the reason might be?
>
> I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.


And don't forget Objective-C, Visual Basic (.NET), Matlab...

On Tuesday, 23 April 2013 at 06:23:56 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
>> You want to explain why the code is bugguy.
>
> Sure. He didn't know the behavior of "==" on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior.

Ho yes, so please explain what is this behavior, I'd be pleased to know.

On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
>
> The trouble is that you've already failed before you started.

Also, I'm assuming that this means that you had no intention of learning. That's kind of a poor position to be in, IMO. That means that I can't help you because you don't want to be helped.

So, I can give you appropriate alternatives (such as tuple) but you won't look at it and see "Oh, jeez, that's actually what I've been using structs for." (Or not, but I can't ever know that's not what you're looking for if you're not going to even try).

And I can't suggest snippets like:

    bool opEquals(T rhs) {
        foreach(i, e; this.tupleof) {
            if(!(e == rhs.tupleof[i]))
                return false;
        }
        return true;
    }

... Which you could use in a mixin to start building a framework of behaviors you can add to _any_ struct to automatically get the behavior you want. We also can't discuss adding this as an attribute using the new attribute system and adding it to the standard library which might be something cool.

No, we have to do it _your_ way and using _your_ understanding, instead of cooperating and getting a better result that we can both agree on.

All I'm saying is that structs are really basic for a reason. They're something you _build_ on. If you don't want to build on it (and you want something already somewhat built), you might be better served using something that _is_ prebuilt. Or make your own platform based on a struct (kinda like how tuples are implemented) and solve it that way.

So many solutions to your problem, yet you've already decided that changing the language is the only "right" way.

On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
>>
>> The trouble is that you've already failed before you started.
>
> Also, I'm assuming that this means that you had no intention of learning.

I could tell you the same thing, but it wouldn't get me anywhere.


> All I'm saying is that structs are really basic for a reason. They're something you _build_ on.

Then they shouldn't define a behavior for == in the first place.


No behavior is better than wrong behavior.

On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
> So many solutions to your problem, yet you've already decided that changing the language is the only "right" way.



I'm just telling you that if no other language has done it, there's a reason behind it.