disabling unary "-" for unsigned types

[Steven Schveighoffer]

On Tue, 16 Feb 2010 13:38:06 -0500, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> What I meant by that statement is that the behavior goes against common  
>> sense -- when it doesn't have to.  It only makes sense to advanced  
>> programmers who understand the inner workings of the CPU and even in  
>> those cases, advance programmers easily make mistakes.
>
> Where you and I disagree is I don't feel that 2s-complement arithmetic  
> is in any way an advanced programming topic. Nor is it an inner working  
> of a CPU - it's an exteriorly visible behavior, well documented in the  
> CPU manuals. (Inner behavior would be things like the microcode.) As I  
> mentioned before, how that works was often the very first topic in an  
> introductory book on programming.

I agree that 2's complement as a whole is not an advanced topic.  What I  
disagree with is the interpretation the result of this one operation.  To  
interpret it as an unsigned value is lunacy.  The result should be  
interpreted as a negative value and not assignable to an unsigned value.   
There are much more sane and unambiguous alternatives to doing this.  Even  
advanced programmers expect when they negate something it most likely  
becomes negative.  It's a surprise when it *always* flips back to positive.

>
> No comprehension of the fundamentals computer arithmetic will lead to  
> failure after failure as a programmer; no language can paper that over.  
> There is no escaping it or pretending it isn't there.

You assume that to understand 2s complement is to understand *and*  
mentally parse why negating a positive value in a computer for unsigned  
types *always* results in a positive value.  I think you can understand 2s  
complement arithmetic and the limitations, and *still* make the mistake of  
assigning the result of negating an unsigned value to an unsigned value.   
There have been already very smart, computer literate, 2s complement  
knowledgeable people who have said on this very newsgroup they have been  
bitten by this error.  This is not a fix to help just newbies.

>> When the result of an operation is 99.999% of the time an error (in  
>> fact the exact percentage is (T.max-1)/T.max  * 100), disallowing it is  
>> worth making the rare valid uses of it illegal.
>
> It conforms to the simple rules of 2s-complement arithmetic, so I  
> disagree with calling it an error.

We're not working in Assembly here.  This is a high level language,  
designed to hide the complexities of the underlying processor.  The  
processor has no idea whether the data in its registers is signed or  
unsigned.  The high level language does.  Please use that knowledge to  
prevent stupid mistakes, or is that not one of the goals of the compiler?   
I can't believe this is such a hard point to get across.

It's not like I'm proposing to change everything about 2s complement math  
*except* in this one small situation: Negation on an unsigned value *and*  
(this part is the most important) assigning it to (or passing it as) an  
unsigned value.  Any time you see that, it is an error or a misguided  
attempt to be clever.

>
>> The case I'm talking about is the equivalent to doing:
>>  x = x / 0;
>
> Even mathematicians don't know what to do about divide by zero. But 2's  
> complement arithmetic is well defined. So the situations are not  
> comparable.

Sure they do, the result is infinity.  It's well defined.  In fact, I  
think some math-based programming languages allow divide by zero.

Again, not arguing against 2s complement here, just the one particular  
situation which is always an error.

-Steve