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 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.
Th
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
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 functio
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, 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 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 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
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 functio
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 with
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 li
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
o
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 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 isn't
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
> -t
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
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();
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)
https://github.com/patefac
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 ov
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:
https://github.com/patef
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?
> > >
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
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 thi
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
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
> > b
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, tha
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
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 in
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 does
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: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
automa
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 *
int.size
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 std.algorithm.equalRecurse(T1,T2)(T
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 sho
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.
By
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, cal
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 ea
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 el
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 element for equality)
else, if it's a class/struct, make sure type
39 matches
Mail list logo
