On Friday, 7 October 2016 at 14:04:10 UTC, Jonathan M Davis wrote:
On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d
wrote:
[...]
It's the plan anyway. It fundamentally doesn't work to have
them on Object and be flexible with attributes, so it was
decided a while ago that they
On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d wrote:
> I find it slightly annoying that the default opCmp throws an
> exception whereas the default opEquals doesn't, but if both of
> these functions are to be removed from Object, as Jonathan M
> Davis stipulates, then all of this is
On Friday, 7 October 2016 at 12:34:34 UTC, Adam D. Ruppe wrote:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
"If opEquals is not specified, the compiler provides a default
version that does member-wise comparison"
That's referring to structs. For classes, it gives an identity
On Friday, October 07, 2016 12:04:09 Mark via Digitalmars-d wrote:
> I'm going over the Object class methods and I have a few concerns
> about the opEquals method.
>
> First, what should be the default implementation of opEquals? The
> specification (see
>
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
"If opEquals is not specified, the compiler provides a default
version that does member-wise comparison"
That's referring to structs. For classes, it gives an identity
comparison function here:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
I'm going over the Object class methods and I have a few
concerns about the opEquals method.
First, what should be the default implementation of opEquals?
The specification (see
https://dlang.org/spec/operatoroverloading.html#eqcmp)
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
I'm going over the Object class methods and I have a few
concerns about the opEquals method.
First, what should be the default implementation of opEquals?
The specification (see
https://dlang.org/spec/operatoroverloading.html#eqcmp)
