On Wednesday, 23 July 2014 at 21:14:35 UTC, Brian Schott wrote:
$ ./dscanner --styleCheck ~/tmp/test.d
test.d(1:8)[warn]: 'A' has method 'opCmp', but not 'opEquals'.
Nice
Am Wed, 15 Oct 2014 11:25:10 +
schrieb Martin Nowak c...@dawg.eu:
On Wednesday, 23 July 2014 at 21:14:35 UTC, Brian Schott wrote:
$ ./dscanner --styleCheck ~/tmp/test.d
test.d(1:8)[warn]: 'A' has method 'opCmp', but not 'opEquals'.
Nice
Yep! Some say opCmp is something entirely
On Wednesday, 23 July 2014 at 21:36:16 UTC, Andrei Alexandrescu
wrote:
There is this notion of partial ordering that makes objects not
smaller and not greater than others, yet not equal. -- Andrei
How do you define a partial ordering using opCmp?
On Friday, 25 July 2014 at 22:29:30 UTC, Walter Bright wrote:
On 7/25/2014 2:55 PM, Jonathan M Davis wrote:
Doesn't the compiler-generated opEquals do a memcmp when it
can?
Yes.
And even sometime when it cannot :D (floats for instance).
On Sunday, 27 July 2014 at 21:16:52 UTC, Ola Fosheim Grøstad
wrote:
But I thought it was confirmed in this thread by the language
designers that == is equality in D, thus === in other
languages are not needed?
For me two instances of a class located at different memory
locations can never be
On Monday, 28 July 2014 at 00:23:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Jul 27, 2014 at 07:04:08PM +, Fool via
Defining opEquals only makes sense if a user wants to replace
equality
by some equivalence relation (different from equality).
Not necessarily. The user type may be
On Monday, 28 July 2014 at 06:05:03 UTC, Fool wrote:
So D has to separate opEquals and opCmp since otherwise a user
could not define floating-point 'equality' and 'comparison'
himself in the same way as it is defined by the language.
I'm convinced know. :-)
But opCmp does not affect and !,
On Monday, 28 July 2014 at 00:23:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Jul 27, 2014 at 07:04:08PM +, Fool via
Digitalmars-d wrote:
Similarly, the user is free to define opCmp without
restriction. In
practice, however, it does not seem to make any sense if =
does not
even
On Sat, 26 Jul 2014 05:22:26 +0100, Walter Bright
newshou...@digitalmars.com wrote:
If you don't want to accept that equality and comparison are
fundamentally different operations, I can only repeat saying the same
things.
For the majority of use cases they are *not* in fact fundamentally
On Fri, 25 Jul 2014 21:38:33 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 7/25/2014 4:10 AM, Regan Heath wrote:
Sure, Andrei makes a valid point .. for a minority of cases. The
majority case
will be that opEquals and opCmp==0 will agree. In those minority cases
where
they
On Monday, 28 July 2014 at 06:05:03 UTC, Fool wrote:
On Monday, 28 July 2014 at 00:23:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Jul 27, 2014 at 07:04:08PM +, Fool via
Defining opEquals only makes sense if a user wants to replace
equality
by some equivalence relation (different
On Monday, 28 July 2014 at 09:37:27 UTC, Regan Heath wrote:
My point was that for the vast majority of coders, in the vast
majority of cases opCmp()==0 will agree with opEquals(). It is
only in very niche cases i.e. where partial ordering is
actually present and important, that this
On 26 July 2014 00:31, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/25/2014 4:28 PM, H. S. Teoh via Digitalmars-d wrote:
That page doesn't say anything about TypeInfo, though.
It says to follow the form.
But even then,
why doesn't the compiler reject opCmp
On 07/23/2014 06:45 PM, H. S. Teoh via Digitalmars-d wrote:
This morning, I discovered this major WAT in D:
struct S {
int x;
int y;
int opCmp(S s) {
return x - s.x; // compare only x
}
}
...
Not even transitive!
void main() {
On 7/26/14, 7:58 PM, Manu via Digitalmars-d wrote:
On 26 July 2014 19:48, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net
mailto:schue...@gmx.net wrote:
On Saturday, 26
In order to get an overview for myself I've summarized the
various properties of different types of orders as they are
described in Wikipedia (right or wrong). I post it here in case
others have an interest in it (or corrections/extensions to it):
* Preorder:
a ≤ a (reflexivity)
if a ≤ b
On Sunday, 27 July 2014 at 13:06:23 UTC, Ola Fosheim Grøstad
wrote:
* Total Preorder:
x ≲ b or b ≲ a (totality).
if a ≲ b and b ≲ c then a ≲ c (transitivity).
x ≲ b (reflexivity; implied by transitivity and totality)
Correction:
* Total Preorder:
a ≲ b or b ≲ a (totality).
if a ≲ b and b
On Saturday, 26 July 2014 at 16:43:06 UTC, Fool wrote:
NaN x is false
NaN x is false
...which means that as it is usually defined on floating
point numbers does not define a strict weak ordering.
Are you sure?
Properties of a Strict Weak Ordering:
#1 not(a a)
#2 not(a b and b c) or
On Sunday, 27 July 2014 at 16:39:01 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 16:43:06 UTC, Fool wrote:
NaN x is false
NaN x is false
...which means that as it is usually defined on floating
point numbers does not define a strict weak ordering.
Are you sure?
One can
On Sunday, 27 July 2014 at 18:00:29 UTC, Fool wrote:
Thus we do not have transitivity of incomparability:
You are right, I forgot to test the case where only c is NaN.
Well, that makes floats suck even more! :-)
On Sunday, 27 July 2014 at 00:43:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
https://github.com/D-Programming-Language/dlang.org/pull/620
Thank you for this.
There is still a problem, I think.
Defining opEquals only makes sense if a user wants to replace
equality by some equivalence
On Sunday, 27 July 2014 at 18:22:50 UTC, Ola Fosheim Gr wrote:
On Sunday, 27 July 2014 at 18:00:29 UTC, Fool wrote:
Thus we do not have transitivity of incomparability:
You are right, I forgot to test the case where only c is NaN.
Well, that makes floats suck even more! :-)
In fact, IEEE
On Sunday, 27 July 2014 at 19:04:09 UTC, Fool wrote:
define ~ such that a ~ b = (a = b or b = a)
^^ and, of course
What should I say, I'm a fool... ;-)
On 7/26/2014 9:46 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 11:27:57PM -0700, Walter Bright via Digitalmars-d wrote:
I welcome a PR from you on this!
https://github.com/D-Programming-Language/dlang.org/pull/620
Thanks!
On Sunday, 27 July 2014 at 19:04:09 UTC, Fool wrote:
If a candidate for opCmp does not match the default equivalence
relation == (defined implicitly or explicitly specified using
opEquals) it should not be defined at all.
Does this mean that you agree that opCmp should define a total
order?
On Sunday, 27 July 2014 at 20:45:25 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 27 July 2014 at 19:04:09 UTC, Fool wrote:
If a candidate for opCmp does not match the default
equivalence relation == (defined implicitly or explicitly
specified using opEquals) it should not be defined at all.
I think that some confusion is due to == is regarded as meaning
equality while it only means equivalence.
Modifying the RGB color example: there is a natural order on
the red channel. Given this ordering, two RGB colors are
equivalent if and only if their red values coincide. In this
sense,
On Sunday, 27 July 2014 at 21:07:08 UTC, Fool wrote:
I think that some confusion is due to == is regarded as meaning
equality while it only means equivalence.
But I thought it was confirmed in this thread by the language
designers that == is equality in D, thus === in other
languages are not
On Sun, Jul 27, 2014 at 07:04:08PM +, Fool via Digitalmars-d wrote:
On Sunday, 27 July 2014 at 00:43:40 UTC, H. S. Teoh via Digitalmars-d wrote:
https://github.com/D-Programming-Language/dlang.org/pull/620
Thank you for this.
There is still a problem, I think.
Defining opEquals only
On Fri, Jul 25, 2014 at 09:22:26PM -0700, Walter Bright via Digitalmars-d wrote:
On 7/25/2014 8:41 PM, Manu via Digitalmars-d wrote:
[...]
It may be correct, if you're lucky, and that's the best offer you'll
get. opCmp==0 however is practically certain to be correct, since =
and = are
On Sat, Jul 26, 2014 at 01:47:20PM +1000, Manu via Digitalmars-d wrote:
On 26 July 2014 06:35, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[...]
So perhaps === is missing, and that's what should be used for AA's,
and also the thing that actually matches the compiler's
On 7/25/2014 11:05 PM, H. S. Teoh via Digitalmars-d wrote:
Well, we can argue about this until the cows come home, but at least for
the present regression being addressed, I think Jonathan's fix is the
best option (or the least of all evils): revert the compiler change that
causes a compile
On 7/25/2014 10:40 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 06:44:36PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
I think we should remove the breakage introduced by requiring opEquals
if opCmp is defined. It breaks good code for no good reason.
Yes, we should
On 26 July 2014 16:13, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, Jul 26, 2014 at 01:47:20PM +1000, Manu via Digitalmars-d wrote:
On 26 July 2014 06:35, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[...]
So perhaps === is missing, and
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via Digitalmars-d
wrote:
It's okay, I hate it too.
But I equally can't abide == meaning something different than
, =, etc.
That's insane.
Yes, it is unsound to use opCmp for types that aren't totally
ordered:
On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via
Digitalmars-d wrote:
It's okay, I hate it too.
But I equally can't abide == meaning something different than
, =, etc.
That's insane.
Yes, it is unsound to use opCmp for
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via Digitalmars-d wrote:
It's okay, I hate it too.
But I equally can't abide == meaning something different than , =,
I agree that the documentation needs improvement.
It needs to be defined what kind of relation opCmp is meant to
model.
If it's concept is a partial order, opEquals cannot be inferred.
If it's concept is a strict weak ordering [1, 2], which is
required for sorting, opEqual can be inferred.
On Saturday, 26 July 2014 at 09:48:55 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net wrote:
Yes, that's why it's possible to provide opEquals in addition
to opCmp.
Not quite, opCmp would then have to throw if opCmp(a,b) is
incomparable. Conflating
On Saturday, 26 July 2014 at 10:43:08 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 09:48:55 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net wrote:
Yes, that's why it's possible to provide opEquals in addition
to opCmp.
Not quite, opCmp would
On Saturday, 26 July 2014 at 09:48:55 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via
Digitalmars-d wrote:
It's okay, I hate it
On Saturday, 26 July 2014 at 12:19:41 UTC, Marc Schütz wrote:
I somehow took your response as disagreement with him.
No, I think it is useful to have a default total sort order for
types even if the order isn't natural and might appear arbitrary.
It is useful in binary trees etc.
That does
On Saturday, 26 July 2014 at 10:22:54 UTC, Fool wrote:
I agree that the documentation needs improvement.
It needs to be defined what kind of relation opCmp is meant to
model.
If it's concept is a partial order, opEquals cannot be inferred.
If it's concept is a strict weak ordering [1, 2],
On Saturday, 26 July 2014 at 13:25:06 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 26 July 2014 at 10:22:54 UTC, Fool wrote:
It needs to be defined what kind of relation opCmp is meant to
model.
If it's concept is a partial order, opEquals cannot be
inferred.
If it's concept is a strict
On Fri, Jul 25, 2014 at 11:27:57PM -0700, Walter Bright via Digitalmars-d wrote:
On 7/25/2014 11:05 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
In the meantime, I think much of the confusion comes from the current
documentation not be adequately clear about the reasoning behind
having opCmp
On 26 July 2014 19:48, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/26/14, 2:19 AM, Marc Schütz schue...@gmx.net wrote:
On Saturday, 26 July 2014 at 07:42:05 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 26 July 2014 at 06:50:11 UTC, Manu via Digitalmars-d
On Friday, 25 July 2014 at 04:50:38 UTC, Walter Bright wrote:
On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13179
Consider also:
http://www.reddit.com/r/programming/comments/2bl51j/programming_in_d_a_great_online_book_for_learning/cj75gm9
On Friday, 25 July 2014 at 05:52:57 UTC, Manu via Digitalmars-d
wrote:
On 25 July 2014 14:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13179
Consider also:
On 7/24/2014 10:52 PM, Manu via Digitalmars-d wrote:
I don't really see how opCmp == 0 could be unreliable or unintended. It was
deliberately written by the author, so definitely not unintended, and I can't
imagine anybody would ever deliberately ignore the == 0 case when implementing
an opCmp,
On 25/07/14 06:50, Walter Bright wrote:
Consider also:
http://www.reddit.com/r/programming/comments/2bl51j/programming_in_d_a_great_online_book_for_learning/cj75gm9
The current scheme breaks existing code - code that was formerly correct
and working.
AAs don't make sense if the notion of ==
On 25/07/14 08:44, Jonathan M Davis wrote:
So, in the case where opCmp was defined but not opEquals, instead of
using the normal, built-in opEquals (which should already be equivalent
to lhs.opCmp(rhs) == 0), we're going to make the compiler generate
opEquals as lhs.opCmp(rhs) == 0? That's a
On 25/07/14 08:31, Jonathan M Davis wrote:
Exactly. The only reason that switching from using lhs.opCmp(rhs) == 0
to opEquals would break code is if a type does not define them such that
they're equivalent, which would mean that opEquals and/or opCmp was
defined in a buggy manner. So, the only
On 25/07/14 08:50, Walter Bright wrote:
Yes, that's why it's hard to see that it would break existing code,
unless that existing code had a bug in it that was worked around in some
peculiar way.
If the type was only used as an AA key and never checked for equivalent
then it worked correctly
On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
3. If opCmp is defined but no opEquals, lhs == rhs will be lowered to
lhs.opCmp(rhs) == 0
This is the sticking point. opCmp and opEquals are separate on purpose, see
Andrei's posts.
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the compiler will make one
for you.
2. AAs use ==. See rule 1.
Easy to understand, easy to explain, easy to document.
On 7/25/2014 1:27 AM, Jacob Carlborg wrote:
On 25/07/14 08:50, Walter Bright wrote:
Yes, that's why it's hard to see that it would break existing code,
unless that existing code had a bug in it that was worked around in some
peculiar way.
If the type was only used as an AA key and never
On 7/25/2014 1:28 AM, Jacob Carlborg wrote:
If the type is only used as an AA key and never checked for equivalent it worked
when opCmp as used for AA keys.
Then we'll just get another bug report from AAs behaving differently from ==.
On 25/07/14 10:55, Walter Bright wrote:
Then we'll just get another bug report from AAs behaving differently
from ==.
No, not as long as it's not used.
--
/Jacob Carlborg
On 25/07/14 10:48, Walter Bright wrote:
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the compiler will
make one for you.
2. AAs use ==. See rule 1.
Easy to understand, easy to explain, easy to document.
It's very hard to use D when it constantly changes and breaks
On 7/25/2014 2:12 AM, Jacob Carlborg wrote:
On 25/07/14 10:48, Walter Bright wrote:
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the compiler will
make one for you.
2. AAs use ==. See rule 1.
Easy to understand, easy to explain, easy to document.
It's very hard to
On 7/25/2014 2:04 AM, Jacob Carlborg wrote:
On 25/07/14 10:55, Walter Bright wrote:
Then we'll just get another bug report from AAs behaving differently
from ==.
No, not as long as it's not used.
Well, that's a forlorn hope :-)
On Friday, 25 July 2014 at 08:21:26 UTC, Jacob Carlborg wrote:
By defining opEquals to be opCmp == 0 we're:
1. We're not breaking code where it wasn't broken previously
2. We're fixing broken code. That is when opEqual and opCmp ==
0 gave different results
Code that worked perfectly fine
On Friday, 25 July 2014 at 09:12:11 UTC, Jacob Carlborg wrote:
On 25/07/14 10:48, Walter Bright wrote:
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the
compiler will
make one for you.
2. AAs use ==. See rule 1.
Easy to understand, easy to explain, easy to
On Friday, 25 July 2014 at 08:02:18 UTC, Jacob Carlborg wrote:
1. If neither opCmp or opEquals are defined, the compiler will
automatically generate these and will be used for comparison
and equivalent
2. If opEquals is defined, lhs == rhs will be lowered to
lhs.opEquals(rhs)
3. If opCmp
Am 25.07.2014 12:07, schrieb Jonathan M Davis:
And once you define opEquals, you have to define
toHash. So, what you're suggesting would force a lot more code to define
toHash, which will likely cause far more bugs than simply requiring that
Is it actually hard to define toHash, or should it
On Friday, 25 July 2014 at 10:27:27 UTC, Daniel Gibson wrote:
Am 25.07.2014 12:07, schrieb Jonathan M Davis:
And once you define opEquals, you have to define
toHash. So, what you're suggesting would force a lot more code
to define
toHash, which will likely cause far more bugs than simply
On Fri, 25 Jul 2014 09:39:11 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
3. If opCmp is defined but no opEquals, lhs == rhs will be lowered to
lhs.opCmp(rhs) == 0
This is the sticking point. opCmp and opEquals are separate on purpose,
On 25/07/14 12:07, Jonathan M Davis wrote:
The compiler _never_ defines opCmp for you. You have to do that
yourself. So, what you're suggesting would force people to define
opEquals just because they defined opCmp unless they wanted to take a
performance hit. And once you define opEquals, you
On 25/07/14 11:46, Jonathan M Davis wrote:
Code that worked perfectly fine before is now slower, because it's using
opCmp for opEquals when it wasn't before.
Who says opCmp need to be slower than opEquals.
Even worse, if you define
opEquals, you're then forced to define toHash, which is
On 25 July 2014 16:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/24/2014 10:52 PM, Manu via Digitalmars-d wrote:
I don't really see how opCmp == 0 could be unreliable or unintended. It
was
deliberately written by the author, so definitely not unintended, and I
On 25/07/14 12:09, Jonathan M Davis wrote:
The _only_ code that would break would be code that's _already_ broken -
code that defines opCmp in a way that's inconsistent with the default
opEquals and then doesn't define opEquals. I see no reason to worry
about making sure that we don't break
On 25/07/14 11:37, Walter Bright wrote:
We went through the likely code breakage from this in this thread, and
it's hard to see any non-broken code breaking. It will also fix
regression https://issues.dlang.org/show_bug.cgi?id=13179 and stop that
breakage.
So opEquals will not be required to
On 7/25/14, 3:31 AM, Jonathan M Davis wrote:
On Friday, 25 July 2014 at 04:50:38 UTC, Walter Bright wrote:
On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13179
Consider also:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via Digitalmars-d
wrote:
On Friday, 25 July 2014 at 08:21:26 UTC, Jacob Carlborg wrote:
By defining opEquals to be opCmp == 0 we're:
1. We're not breaking code where it wasn't broken previously
2. We're fixing broken code. That is
On Fri, Jul 25, 2014 at 12:10:31PM +0100, Regan Heath via Digitalmars-d wrote:
On Fri, 25 Jul 2014 09:39:11 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
3. If opCmp is defined but no opEquals, lhs == rhs will be lowered
to lhs.opCmp(rhs)
On Fri, Jul 25, 2014 at 02:08:55PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 25/07/14 12:09, Jonathan M Davis wrote:
The _only_ code that would break would be code that's _already_
broken - code that defines opCmp in a way that's inconsistent with
the default opEquals and then
On Fri, Jul 25, 2014 at 02:37:46AM -0700, Walter Bright via Digitalmars-d wrote:
On 7/25/2014 2:12 AM, Jacob Carlborg wrote:
On 25/07/14 10:48, Walter Bright wrote:
Putting it simply,
1. == uses opEquals. If you don't supply opEquals, the compiler will
make one for you.
2. AAs use ==.
On Friday, 25 July 2014 at 13:44:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 12:10:31PM +0100, Regan Heath via
Digitalmars-d wrote:
On Fri, 25 Jul 2014 09:39:11 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
3. If
And it's not like we're making it impossible in the minority
case -- if
you want a non-linear partial ordering, wouldn't you make sure
to define
both opCmp and opEquals so that they do the right thing? Since
it's an
uncommon use case, people would tend to be more careful when
implementing it.
On Friday, 25 July 2014 at 14:10:11 UTC, H. S. Teoh via
Digitalmars-d wrote:
The whole reason the opCmp()==0 thing was brought up, was to
eliminate
this frustration -- give users a nice way to transition into
the correct
AA design of using opEquals for their keys, instead of just
outright
On Thursday, 24 July 2014 at 08:18:22 UTC, Daniel Gibson wrote:
When I implement the comparison operator for my type, I
expect it to be used for comparisons - and that includes
equality.
If I had the feeling that I could implement == in a more
efficient way, or that I actually want equality to
On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via
Digitalmars-d wrote:
Even worse, if you define opEquals, you're then forced to
define
toHash, which is much harder to get right.
If you're redefining
Am 25.07.2014 18:11, schrieb Marc Schütz schue...@gmx.net:
I'm astonished that it doesn't work like that already. When I first read
the operator overloading docs, I really liked that in D I don't need to
define all the individual comparison operators, but only opCmp. I
Well, to be fair the
Am 25.07.2014 20:45, schrieb Jonathan M Davis:
On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via
Digitalmars-d wrote:
Even worse, if you define opEquals, you're then forced to define
toHash, which is much
On Friday, 25 July 2014 at 12:08:55 UTC, Jacob Carlborg wrote:
On 25/07/14 12:09, Jonathan M Davis wrote:
The _only_ code that would break would be code that's
_already_ broken -
code that defines opCmp in a way that's inconsistent with the
default
opEquals and then doesn't define opEquals. I
On Friday, 25 July 2014 at 18:54:07 UTC, Daniel Gibson wrote:
Am 25.07.2014 20:45, schrieb Jonathan M Davis:
On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via
Digitalmars-d
wrote:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via
Digitalmars-d wrote:
Even worse, if you
On Friday, 25 July 2014 at 18:45:30 UTC, Jonathan M Davis wrote:
On Friday, 25 July 2014 at 13:34:55 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jul 25, 2014 at 09:46:55AM +, Jonathan M Davis via
Digitalmars-d wrote:
Even worse, if you define opEquals, you're then forced to
define
On Friday, 25 July 2014 at 18:54:15 UTC, Daniel Gibson wrote:
Am 25.07.2014 18:11, schrieb Marc Schütz schue...@gmx.net:
I'm astonished that it doesn't work like that already. When I
first read
the operator overloading docs, I really liked that in D I
don't need to
define all the individual
On Friday, 25 July 2014 at 13:44:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
Exactly!! I don't understand why people keep bringing up
non-linear
partial orderings -- those only apply in a *minority* of cases!
Well, if , = etc are only to be used where you have a natural
total order then I
On 2014-07-25 15:51, H. S. Teoh via Digitalmars-d wrote:
AA's don't care about keys being orderable, all they care about is that
keys should have a hash value, and be comparable. It was a mistake to
use opCmp for AA keys in the first place. We're now fixing this mistake.
I'm responding to
On 2014-07-25 20:56, Jonathan M Davis wrote:
opEquals will now be used for AA keys, not opCmp.
Well, yes. But that was not the case when the code was written. In that
case it was to correct to defined opCmp.
That's why git master
generates errors when you have a struct which defines opCmp
On Fri, Jul 25, 2014 at 07:21:04PM +, via Digitalmars-d wrote:
On Friday, 25 July 2014 at 13:44:54 UTC, H. S. Teoh via Digitalmars-d wrote:
Exactly!! I don't understand why people keep bringing up non-linear
partial orderings -- those only apply in a *minority* of cases!
Well, if , = etc
On Friday, 25 July 2014 at 19:03:16 UTC, Marc Schütz wrote:
On Friday, 25 July 2014 at 18:45:30 UTC, Jonathan M Davis wrote:
And remember that a lot of types have opCmp just to work with
AAs, so all of a sudden, _every_ user-defined type which is
used as an AA key will have to define toHash.
On 7/25/2014 5:10 AM, Jacob Carlborg wrote:
On 25/07/14 11:37, Walter Bright wrote:
We went through the likely code breakage from this in this thread, and
it's hard to see any non-broken code breaking. It will also fix
regression https://issues.dlang.org/show_bug.cgi?id=13179 and stop that
On 7/25/2014 7:08 AM, H. S. Teoh via Digitalmars-d wrote:
You're missing the fact that:
1) Before we fixed the use of typeinfo.compare in aaA.d, users were
*required* to define opCmp in order for their types to be usable as AA
keys -- because that's what aaA.d used to compare keys. This applies
On Friday, 25 July 2014 at 20:07:08 UTC, Jacob Carlborg wrote:
On 2014-07-25 20:56, Jonathan M Davis wrote:
opEquals will now be used for AA keys, not opCmp.
Well, yes. But that was not the case when the code was written.
In that case it was to correct to defined opCmp.
Yes, but opCmp
On 7/25/2014 5:08 AM, Jacob Carlborg wrote:
I see no reason why I should define opEquals when opCmp was used for AA keys.
You keep ignoring that argument.
Allow me to repeat:
The thing is, either this suffers from == behaving differently than AAs, or
you've made opEquals superfluous by
On 7/25/2014 5:10 AM, Ary Borenszweig wrote:
Not at all.
If you have a type that has partial ordering (only cares about opCmp, not about
opEquals), but still keeps the default opEquals, then this would silently break
someone's code by changing their opEquals semantic.
THIS is the breaking
On 7/25/2014 4:10 AM, Regan Heath wrote:
Sure, Andrei makes a valid point .. for a minority of cases. The majority case
will be that opEquals and opCmp==0 will agree. In those minority cases where
they are intended to disagree the user will have intentionally defined both, to
be different. I
On Friday, 25 July 2014 at 20:13:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
Nobody said anything
about making it *impossible* to define non-linear orderings.
But opCmp() already make it impossible to define some binary
relations that are order-like for , = etc. You cannot return
both -1 and
1 - 100 of 163 matches
Mail list logo
