On Wednesday, 20 March 2013 at 03:10:41 UTC, Jonathan M Davis
wrote:
The way == is defined is very clean and straightforward. There
_are_ bugs which
complicate things (e.g.
http://d.puremagic.com/issues/show_bug.cgi?id=3789 ),
but those can and will be fixed. The design itself is solid.
On Wednesday, March 20, 2013 12:47:38 Dan wrote:
I would
imagine by now there is a fair amount of code that might rely on
a false result from opEquals if the members (slices, associative
arrays) are not bitwise the same.
I think that it's more likely that there's a lot of code that expects
On Tuesday, 19 March 2013 at 08:25:45 UTC, timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range, call std.algorithm.equal (ie compare nb
elements, then each
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range, call std.algorithm.equal (ie compare nb
elements, then each
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
else, if its a range,
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
A similar function seems useful for Phobos because it's
automatic, you don't need to tell it how many levels there are.
On Tuesday, 19 March 2013 at 11:46:14 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis
wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior
On Tuesday, 19 March 2013 at 12:16:54 UTC, John Colvin wrote:
On Tuesday, 19 March 2013 at 11:46:14 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 10:08:43 UTC, Jonathan M Davis
wrote:
On Tuesday, March 19, 2013 09:25:43 timotheecour wrote:
we need a
On Tuesday, 19 March 2013 at 12:16:54 UTC, John Colvin wrote:
(except if you feed it two integer literals, in which case the
compiler throws an out of memory error!).
Which is a legitimate error, seeing as -1 as a size_t is
size_t.max which meant replicate was requesting size_t.max *
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
A similar function seems useful for Phobos because it's
On Tuesday, 19 March 2013 at 12:34:04 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it does happen, you can simply nest equal as many
times as you need.
On Tuesday, 19 March 2013 at 12:36:34 UTC, John Colvin wrote:
On Tuesday, 19 March 2013 at 12:34:04 UTC, monarch_dodra wrote:
On Tuesday, 19 March 2013 at 12:11:50 UTC, bearophile wrote:
Jonathan M Davis:
Going beyond a range of ranges is likely to be quite rare,
I agree.
and when it
I think none of you got the point of equalRecurse, so let me
clarify.
equalRecurse should work on any type, not just inputRanges, see
my example in the OT with a struct containing an array: currently
std.algorithm.equal has isInputRange conditions on the arguments.
So, yes, it can go deep
On Tuesday, March 19, 2013 18:08:53 timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
equalRecurse should work on any type, not just inputRanges,
Which is fundamentally wrong. == and equal are two very different operations,
even if their intent may be
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
recursive (to specified level) toStringRecurse that would
belong there too.
Also, I'd add to that list copyRecurse and some more,
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
recursive (to specified level) toStringRecurse that would
belong there
On Tue, Mar 19, 2013 at 01:48:43PM -0400, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also, the OT's firstDifference would go there too, and I have a
And how do you even have the concept of recursion without some
sort of range or container to recursively iterate through?
It's not hard: I've done it for a serialization library I've been
working on (which has some advantages over std.orange, such as
serializing to json/binary etc. more on
On Tuesday, 19 March 2013 at 08:25:45 UTC, timotheecour wrote:
we need a std.algorithm.equalRecurse(T1,T2)(T1 a, T2 b) that
compares recursively a and b;
its behavior should be:
if opEqual is defined, call it
The problem is, Object defines opEqual as bool opEquals(Object
o){return this is
On Tuesday, March 19, 2013 11:12:38 H. S. Teoh wrote:
On Tue, Mar 19, 2013 at 01:48:43PM -0400, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 18:26:16 timotheecour wrote:
somewhere else, but I don't see a relevant package. Maybe a new
std.algorithm2 for non-ranges?
Also,
On Tuesday, 19 March 2013 at 17:08:54 UTC, timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
I think I understand what you are after and I like the idea. I've
got a few:
-typesDeepEqual
-typesDeepCmp
-deepHash
Have a look at:
On Tuesday, March 19, 2013 19:13:14 timotheecour wrote:
And how do you even have the concept of recursion without some
sort of range or container to recursively iterate through?
It's not hard: I've done it for a serialization library I've been
working on (which has some advantages over
I think I understand what you are after and I like the idea.
I've got a few:
-typesDeepEqual
-typesDeepCmp
-deepHash
approxEqualRecurse could also be useful for numerical
applications (same as equalRecurse, except uses approxEqual for
floating point comparisons)
That's opEquals' job. It deals with recursive comparisons like
you're describing here just fine.
Except the functionality is very different, as opEquals is blind
to range semantics. I want equalRecurse to work as follows:
struct A{ int[]b=[1]; }
void main(){
auto a1=A();
On Tuesday, March 19, 2013 21:13:21 timotheecour wrote:
That's opEquals' job. It deals with recursive comparisons like
you're describing here just fine.
Except the functionality is very different, as opEquals is blind
to range semantics.
opEquals defines equality however it chooses to
On Tuesday, March 19, 2013 20:36:09 Dan wrote:
On Tuesday, 19 March 2013 at 17:08:54 UTC, timotheecour wrote:
I think none of you got the point of equalRecurse, so let me
clarify.
I think I understand what you are after and I like the idea. I've
got a few:
-typesDeepEqual
On Tuesday, 19 March 2013 at 20:28:09 UTC, Jonathan M Davis wrote:
Those are what opEquals, opCmp, and toHash are for. It might
make sense to
define mixins which implement them for you (dealing with
whatever recursive
semantics are necessary), but using external functions for
those just
On Tuesday, March 19, 2013 21:50:55 Dan wrote:
On Tuesday, 19 March 2013 at 20:28:09 UTC, Jonathan M Davis wrote:
The language and standard library are designed around them being
part of the types themselves. Stuff like AAs won't work if
those functions
aren't defined on the types
On Tuesday, 19 March 2013 at 21:11:12 UTC, Jonathan M Davis wrote:
Lots of stuff uses ==, toHash, etc. That's the way the language
is designed.
Agreed
Defining your types without defining those properly just isn't
going to work for
a _lot_ of stuff. Creating an external function to compare
On Tuesday, March 19, 2013 22:43:10 Dan wrote:
The above works with the built-in AAs.
Please offer an example.
It works because the outer type defines toHash. Without toHash, the built-in
AAs won't work. If you're dealing with member variables which don't have
toHash, then doing something
On Tuesday, 19 March 2013 at 23:13:19 UTC, Jonathan M Davis wrote:
On Tuesday, March 19, 2013 22:43:10 Dan wrote:
The above works with the built-in AAs.
Please offer an example.
It works because the outer type defines toHash. Without toHash,
the built-in
AAs won't work. If you're dealing
On Wednesday, March 20, 2013 01:17:13 Dan wrote:
This is true, but then my code is by definition not standard.
However, theoretically, the language writers could. For example,
any '==' could be lowered to a 'standard' function, probably
better named 'intancesDeepEqual(a,b)' and that function
On Wed, Mar 20, 2013 at 01:17:13AM +0100, Dan wrote:
On Tuesday, 19 March 2013 at 23:13:19 UTC, Jonathan M Davis wrote:
[...]
But the main problem that I'm pointing out is that you can't define
your own, non-standard functions for equality or hashing or whatever
and expect your types to play
On Tuesday, March 19, 2013 18:20:35 H. S. Teoh wrote:
I like this idea. By default, provide something that recursively
compares struct/class members, array elements, etc.. But if at any level
an opEquals is defined, then that is used instead. This maximizes
convenience for those cases where
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's just
that it uses ==
on each member, so if == doesn't work for a particular member
variable and the
semantics you want for == on the type it's in, you need to
override
On Wednesday, March 20, 2013 03:48:38 Dan wrote:
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's just
that it uses ==
on each member, so if == doesn't work for a particular member
variable and the
On Wednesday, March 20, 2013 01:17:13 Dan wrote:
This is true, but then my code is by definition not standard.
However, theoretically, the language writers could. For example,
any '==' could be lowered to a 'standard' function, probably
better named 'intancesDeepEqual(a,b)' and that function
On Wednesday, 20 March 2013 at 02:54:23 UTC, Jonathan M Davis
wrote:
On Wednesday, March 20, 2013 03:48:38 Dan wrote:
On Wednesday, 20 March 2013 at 02:03:31 UTC, Jonathan M Davis
wrote:
We already get this. That's what == does by default. It's
just
that it uses ==
on each member, so if
38 matches
Mail list logo
