Arcane Jill wrote:
> In article <cjcimp$2spj$1@digitaldaemon.com>, Sean Kelly says...
> 
[snip]
>>I would mimic this behavior.
> 
> 
> It is not possible to mimic the behavior of float or complex primatives in an
> object, because opCmp() just is not powerful enough (it doesn't handle the cases
> <>= or !<>=).

You can with a value type if you return float from opCmp:

    bit opEquals (Type other)
    {
         return opCmp (other) == 0;
    }

    float opCmp (Type other)
    {
        if (value < other.value)
            return -1;
        if (value > other.value)
            return +1;
        if (value == other.value)
            return 0;
        return float.nan;
    }

That'll work correctly for all comparisons (yes, I tested).  So all Object.opCmp needs is to return float.

"ajvincent" <ajvincent_member@pathlink.com> wrote in message news:cjcsp3$15m$1@digitaldaemon.com...
> class Foo {
> private bit[] bool = [0];
>
> unittest {
> Foo a = new Foo;
> Foo b = new Foo;
> a.bool[0] = 1;
> assert(b.bool[0] == 0);
> }
> }
>
> int main() {
> return 0;
> }
>
> One is left to wonder if that was a bug on the part of the programmer or
not.

This should be the same issue as for string literals. The field "bool"
(confusing name, by the way, given that bool is defined in object.d as an
alias for bit) is initialized to have length 1 and data pointer pointing to
a shared (read-only on Linux) bit containing 0. To obtain distinct copies
one needs to have a constructor that allocates the array:
class Foo {
  private bit[] bool;
  this() { bool = new bit[1]; }
  unittest {
    Foo a = new Foo;
    Foo b = new Foo;
    a.bool[0] = 1;
    assert(b.bool[0] == 0);
  }
}

int main() {
  return 0;
}