On Saturday, 25 January 2014 at 17:15:56 UTC, Ola Fosheim Grøstad wrote:
> Fortunately most CPUS have ones-complement so the result is

Err... "Two's complement." Nngh! Anyway, the basic idea is to think of minus for unsigned integers as ~x + 1, not as a operation using negative integers. Then it makes sense.

On 1/25/14 9:15 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 24 January 2014 at 22:59:08 UTC, Andrei Alexandrescu wrote:
>> integral expressions are handled. For example I found it ridiculous
>> that unary "-" for uint returns uint. Walter talked
>
> Fortunately most CPUS have ones-complement so the result is correct if
> you only use one unsigned type.

???

Andrei

On 1/25/14 9:35 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Saturday, 25 January 2014 at 17:15:56 UTC, Ola Fosheim Grøstad wrote:
>> Fortunately most CPUS have ones-complement so the result is
>
> Err... "Two's complement." Nngh! Anyway, the basic idea is to think of
> minus for unsigned integers as ~x + 1, not as a operation using negative
> integers. Then it makes sense.

Of course it does. It was the point of my post. It's just that the type is surprising from a basic arithmetic viewpoint.

Andrei

On Saturday, 25 January 2014 at 18:53:29 UTC, Andrei Alexandrescu wrote:
> Of course it does. It was the point of my post. It's just that the type is surprising from a basic arithmetic viewpoint.

Yes, I agree. I think it is messy to have implicit promotion of unsigned values. For signed ints you get sign-expansion, so they are less problematic.

If the programmer does not care about bit-patterns he probably just uses regular ints anyway, so why promote when it create bugs that are hard to track down?

Timon Gehr wrote:
> On 01/24/2014 11:33 PM, Walter Bright wrote:
>> ...
>> 2. types do not depend on particular runtime values (the whole notion of
>> static typing would fall apart if it did)
>
> http://en.wikipedia.org/wiki/Dependent_type

http://en.wikipedia.org/wiki/Refinement_type#Refinement_types

On Saturday, 25 January 2014 at 13:43:25 UTC, Timon Gehr wrote:
> Why not?
>
> struct S{
>     auto opCmp(S r){ return float.nan; }
> }
>
> void main(){
>     S s;
>     assert(s!<>=s);
> }

Yes, but only for floatingpoint types - you cannot overload the !<>= operator for integral types and it will be deprecated anyway.
And you cannot opverload opCmp in a way that the new defined integer NaN will not compare in some way to the other integer values.
What would be needed is a minimal signed type (2bit with the values -1, 0, 1 and NaN) and use that in opCmp.

On 01/27/2014 02:46 PM, Dominikus Dittes Scherkl wrote:
> On Saturday, 25 January 2014 at 13:43:25 UTC, Timon Gehr wrote:
>>On 01/25/2014 01:57 PM, Dominikus Dittes Scherkl wrote:
>>> And then comparison cannot be implemented fully correct with the current
>>> operator overloding system of D.
>> Why not?
>>
>> struct S{
>>     auto opCmp(S r){ return float.nan; }
>> }
>>
>> void main(){
>>     S s;
>>     assert(s!<>=s);
>> }
>
> Yes, but only for floatingpoint types - you cannot overload the !<>=
> operator for integral types

I don't get what this is supposed to mean.

> and it will be deprecated anyway.

So? It was the most convenient way to illustrate that I have defined a not fully ordered type using opCmp.

> And you cannot opverload opCmp in a way that the new defined integer NaN
> will not compare in some way to the other integer values.

Of course you can. Just return float.nan from opCmp in the case that at least one of the arguments is your 'integer NaN'.

float opCmp(sint r){
    if(isNan()||r.isNan()) return float.nan;
    return value<r.value?-1:value>r.value?1:0;
}

> What would be needed is a minimal signed type (2bit with the values -1,
> 0, 1 and NaN) and use that in opCmp.

That's not needed in order to get correct comparison behaviour.

On 1/27/14 6:13 AM, Timon Gehr wrote:
> float opCmp(sint r){
>      if(isNan()||r.isNan()) return float.nan;
>      return value<r.value?-1:value>r.value?1:0;
> }

Quite a nice trick.

Andrei

On Monday, 27 January 2014 at 14:13:36 UTC, Timon Gehr wrote:
> So? It was the most convenient way to illustrate that I have defined a not fully ordered type using opCmp.
Was not my idea to deprecate them :-/
>
>> And you cannot opverload opCmp in a way that the new defined integer NaN
>> will not compare in some way to the other integer values.
>
> Of course you can. Just return float.nan from opCmp in the case that at least one of the arguments is your 'integer NaN'.
>
> float opCmp(sint r){
>     if(isNan()||r.isNan()) return float.nan;
>     return value<r.value?-1:value>r.value?1:0;
> }
>
>> What would be needed is a minimal signed type (2bit with the values -1,
>> 0, 1 and NaN) and use that in opCmp.
>
> That's not needed in order to get correct comparison behaviour.

Ah, ok. Now I understand. not inventing a type with NaN, but instead using one that provides it - really a nice trick. I never thought of a comparison operator returning a float.

Cool. Thank you very much.