Good day.

There's a problem in how opCmp works.

I have a structure, that represents an element of a range. Let's say a
character. That character can be invalid.
I need all comparison operators to return false of at least one of the
operands is invalid.
with opCmp, the expression a @ b is rewritten as a.opCmp(B) @ 0, which
doesn't allow me to define such a logic.
wouldn't it be better to change the rewrite of opCmp to test for exact
values -1, 0 and 1? In that case I could return 2 and have all
comparisons fail.

-- 
Bye,
Gor Gyolchanyan.

On 02/03/2012 06:44 AM, Gor Gyolchanyan wrote:
> Good day.
>
> There's a problem in how opCmp works.
>
> I have a structure, that represents an element of a range. Let's say a
> character. That character can be invalid.
> I need all comparison operators to return false of at least one of the
> operands is invalid.

As an observation, you want to implement the concept of "unordered" for types, similar to floating point types:

  http://dlang.org/expression.html#floating_point_comparisons

I am very surprised that the following operator works with non-floating-point types:

class C
{
    override int opCmp(Object o)
    {
        return 0;
    }
}

void main()
{
    auto c = new C;
    auto b = (c !<>= c);      // <-- compiles!

    int i, j;
    auto b2 = (i !<>= j);     // <-- compiles!
}

Is that supported? Is it a bug? Would using those /unordered/ operator help in your case?

> with opCmp, the expression a @ b is rewritten as a.opCmp(B) @ 0, which
> doesn't allow me to define such a logic.
> wouldn't it be better to change the rewrite of opCmp to test for exact
> values -1, 0 and 1? In that case I could return 2 and have all
> comparisons fail.
>

Ali

Bug!

"Ali Çehreli" <acehreli@yahoo.com> wrote in message news:jgh2nb$rtv$1@digitalmars.com...
> On 02/03/2012 06:44 AM, Gor Gyolchanyan wrote:
> > Good day.
> >
> > There's a problem in how opCmp works.
> >
> > I have a structure, that represents an element of a range. Let's say a
> > character. That character can be invalid.
> > I need all comparison operators to return false of at least one of the
> > operands is invalid.
>
> As an observation, you want to implement the concept of "unordered" for types, similar to floating point types:
>
>   http://dlang.org/expression.html#floating_point_comparisons
>
> I am very surprised that the following operator works with non-floating-point types:
>
> class C
> {
>     override int opCmp(Object o)
>     {
>         return 0;
>     }
> }
>
> void main()
> {
>     auto c = new C;
>     auto b = (c !<>= c);      // <-- compiles!
>
>     int i, j;
>     auto b2 = (i !<>= j);     // <-- compiles!
> }
>
> Is that supported? Is it a bug? Would using those /unordered/ operator help in your case?
>
> > with opCmp, the expression a @ b is rewritten as a.opCmp(B) @ 0, which
> > doesn't allow me to define such a logic.
> > wouldn't it be better to change the rewrite of opCmp to test for exact
> > values -1, 0 and 1? In that case I could return 2 and have all
> > comparisons fail.
> >
>
> Ali
> 

How do I overload the unordered comparison operators? do I overload them one by one? If I do what happens if I also define the opCmp?

On Fri, Feb 3, 2012 at 8:41 PM, Ali Çehreli <acehreli@yahoo.com> wrote:
> On 02/03/2012 06:44 AM, Gor Gyolchanyan wrote:
>> Good day.
>>
>> There's a problem in how opCmp works.
>>
>> I have a structure, that represents an element of a range. Let's say a
>> character. That character can be invalid.
>> I need all comparison operators to return false of at least one of the
>> operands is invalid.
>
> As an observation, you want to implement the concept of "unordered" for types, similar to floating point types:
>
>  http://dlang.org/expression.html#floating_point_comparisons
>
> I am very surprised that the following operator works with non-floating-point types:
>
> class C
> {
>    override int opCmp(Object o)
>    {
>        return 0;
>    }
> }
>
> void main()
> {
>    auto c = new C;
>    auto b = (c !<>= c);      // <-- compiles!
>
>    int i, j;
>    auto b2 = (i !<>= j);     // <-- compiles!
> }
>
> Is that supported? Is it a bug? Would using those /unordered/ operator help in your case?
>
>
>> with opCmp, the expression a @ b is rewritten as a.opCmp(B) @ 0, which
>> doesn't allow me to define such a logic.
>> wouldn't it be better to change the rewrite of opCmp to test for exact
>> values -1, 0 and 1? In that case I could return 2 and have all
>> comparisons fail.
>>
>
> Ali
>



-- 
Bye,
Gor Gyolchanyan.

http://d.puremagic.com/issues/show_bug.cgi?id=7430
Please vote on this, so it would get some attention.

On Fri, Feb 3, 2012 at 8:45 PM, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> Bug!
>
> "Ali Çehreli" <acehreli@yahoo.com> wrote in message news:jgh2nb$rtv$1@digitalmars.com...
>> On 02/03/2012 06:44 AM, Gor Gyolchanyan wrote:
>> > Good day.
>> >
>> > There's a problem in how opCmp works.
>> >
>> > I have a structure, that represents an element of a range. Let's say a
>> > character. That character can be invalid.
>> > I need all comparison operators to return false of at least one of the
>> > operands is invalid.
>>
>> As an observation, you want to implement the concept of "unordered" for types, similar to floating point types:
>>
>>   http://dlang.org/expression.html#floating_point_comparisons
>>
>> I am very surprised that the following operator works with non-floating-point types:
>>
>> class C
>> {
>>     override int opCmp(Object o)
>>     {
>>         return 0;
>>     }
>> }
>>
>> void main()
>> {
>>     auto c = new C;
>>     auto b = (c !<>= c);      // <-- compiles!
>>
>>     int i, j;
>>     auto b2 = (i !<>= j);     // <-- compiles!
>> }
>>
>> Is that supported? Is it a bug? Would using those /unordered/ operator help in your case?
>>
>> > with opCmp, the expression a @ b is rewritten as a.opCmp(B) @ 0, which
>> > doesn't allow me to define such a logic.
>> > wouldn't it be better to change the rewrite of opCmp to test for exact
>> > values -1, 0 and 1? In that case I could return 2 and have all
>> > comparisons fail.
>> >
>>
>> Ali
>>
>
>



-- 
Bye,
Gor Gyolchanyan.