> That I partially, fractionally even, agree with. We agonized for a long time about what to do to improve on the state of the art back in 2007 - literally months I recall. Part of the conclusion was that reverting to int for object lengths would be a net negative.
>
> Andrei

All of these discussions, let me known how to do about 'length',D better than c,it's a system language.

For WindowsAPI: cast(something)length ,and other modify it to size_t.

Thank you all.

On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
> If this kind of unsafe mixing wasn't allowed, or required explict casts
> (to signify "yes I know what I'm doing and I'm prepared to face the
> consequences"), I suspect that bearophile would be much happier about
> this issue. ;-)

Explicit casts are worse than the problem - they can easily cause bugs.

As for me personally, I like having a complete set of signed and unsigned integral types at my disposal. It's like having a full set of wrenches that are open end on one end and boxed on the other :-) Most of the time either end will work, but sometimes only one will.

Now, if D were a non-systems language like Basic, Go or Java, unsigned types could be reasonably dispensed with. But D is a systems programming language, and it ought to have available types that match what the hardware supports.

On 11/19/2014 10:09 AM, Ary Borenszweig wrote:
> I agree. An array's length makes sense as an unsigned ("an array can't have a
> negative length, right?") but it leads to the bugs you say. For example:
>
> ~~~
> import std.stdio;
>
> void main() {
>    auto a = [1, 2, 3];
>    auto b = [1, 2, 3, 4];
>    if (a.length - b.length > 0) {
>      writeln("Can you spot the bug that easily?");

Yes.

>    }
> }
> ~~~
>
> Yes, it makes sense, but at the same time it leads to super unintuitive math
> operations being involved.

Computer math is not math math. It is its own beast, and if you're going to write in a systems programming language it is very important to learn how it works, or you'll be nothing but frustrated.


> Rust made the same mistake and now a couple of times I've seen bugs like these
> being reported. Never seen them in Java or .Net though. I wonder why...

D is meant to be easily used by C and C++ programmers. It follows the same model of signed/unsigned arithmetic and integral promotions. This is very, very deliberate. To change this would be a disaster.

For example, in America we drive on the right. In Australia, they drive on the left. When I visit Australia, I know this, but when stepping out into the road I instinctively check my left for cars, step into the road, and my foot gets run over by a car coming from the right. I've had to be very careful as a pedestrian there, as my intuition would get me killed.

Don't mess with systems programmers' intuitions. It'll cause more problems than it solves.

On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu wrote:
> On 11/19/14 6:04 AM, Don wrote:
>> Almost everybody seems to think that unsigned means positive. It does not.
>
> That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white.
>
> Andrei

Even in the responses in this thread indicate that about half of the people here don't understand unsigned.

"unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative".

Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.

> "With only a bit of care one can use D's unsigned types for positive numbers."

I do not believe that that statement to be true. I believe that bugs caused by unsigned calculations are subtle and require an extraordinary level of diligence. I showed an example at DConf, that I had found in production code.

It's particularly challenging in D because of the widespread use of 'auto':

auto x = foo();
auto y = bar();
auto z = baz();

if (x - y > z) { ... }


This might be a bug, if one of these functions returns an unsigned type.  Good luck finding that. Note that if all functions return unsigned, there isn't even any signed-unsigned mismatch.

I believe the correct statement, is "With only a bit of care one can use D's unsigned types for positive numbers and believe that one's code is correct, even though it contains subtle bugs."

On 11/20/14 12:18 AM, Don wrote:
> On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu wrote:
>> On 11/19/14 6:04 AM, Don wrote:
>>> Almost everybody seems to think that unsigned means positive. It does
>>> not.
>>
>> That's an exaggeration. With only a bit of care one can use D's
>> unsigned types for positive numbers. Please let's not reduce the
>> matter to black and white.
>>
>> Andrei
>
> Even in the responses in this thread indicate that about half of the
> people here don't understand unsigned.
>
> "unsigned" means "I want to use modulo 2^^n arithmetic". It does not
> mean, "this is an integer which cannot be negative".
>
> Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to
> represent a non-negative integer, you are using the incorrect type.
>
>> "With only a bit of care one can use D's unsigned types for positive
>> numbers."
>
> I do not believe that that statement to be true. I believe that bugs
> caused by unsigned calculations are subtle and require an extraordinary
> level of diligence. I showed an example at DConf, that I had found in
> production code.
>
> It's particularly challenging in D because of the widespread use of 'auto':
>
> auto x = foo();
> auto y = bar();
> auto z = baz();
>
> if (x - y > z) { ... }
>
>
> This might be a bug, if one of these functions returns an unsigned
> type.  Good luck finding that. Note that if all functions return
> unsigned, there isn't even any signed-unsigned mismatch.
>
> I believe the correct statement, is "With only a bit of care one can use
> D's unsigned types for positive numbers and believe that one's code is
> correct, even though it contains subtle bugs."

Well I'm sorry but I quite disagree. -- Andrei

On Thursday, 20 November 2014 at 08:14:41 UTC, Walter Bright wrote:
> Computer math is not math math. It is its own beast, and if you're going to write in a systems programming language it is very important to learn how it works, or you'll be nothing but frustrated.

Understanding how it works doesn't mean error prone practices must be forced everywhere. It's not like D can't work with signed types.

>> Rust made the same mistake and now a couple of times I've seen bugs like these
>> being reported. Never seen them in Java or .Net though. I wonder why...
>
> D is meant to be easily used by C and C++ programmers. It follows the same model of signed/unsigned arithmetic and integral promotions. This is very, very deliberate. To change this would be a disaster.

If unsigned types exist, it doesn't mean they must be forced everywhere.

> For example, in America we drive on the right. In Australia, they drive on the left. When I visit Australia, I know this, but when stepping out into the road I instinctively check my left for cars, step into the road, and my foot gets run over by a car coming from the right. I've had to be very careful as a pedestrian there, as my intuition would get me killed.
>
> Don't mess with systems programmers' intuitions. It'll cause more problems than it solves.

Bad things can happen, but why make them more probable instead of trying to make them less probable?

On Thursday, 20 November 2014 at 01:05:51 UTC, H. S. Teoh via Digitalmars-d wrote:
> However, the fact that you can freely mix signed and unsigned types in
> unsafe ways without any warning, is a fly that spoils the soup.
>
> If this kind of unsafe mixing wasn't allowed, or required explict casts
> (to signify "yes I know what I'm doing and I'm prepared to face the
> consequences"), I suspect that bearophile would be much happier about
> this issue. ;-)

If usage of unsigned types is not controlled, they will systematically mix with signed types, the mix becomes normal flow of the code. Disallowing normal flow of the code is even worse.

>> auto x = foo();
>> auto y = bar();
>> auto z = baz();
>>
>> if (x - y > z) { ... }
>>
>>
>> This might be a bug, if one of these functions returns an unsigned
>> type.  Good luck finding that. Note that if all functions return
>> unsigned, there isn't even any signed-unsigned mismatch.
>>
>> I believe the correct statement, is "With only a bit of care one can use
>> D's unsigned types for positive numbers and believe that one's code is
>> correct, even though it contains subtle bugs."
>
> Well I'm sorry but I quite disagree. -- Andrei

This might be a bug.

'Length' always needs to compare sizes. 'Width' and 'Height' like it.

************************ dfl/drawing.d line:185 -218 **************************

	///
	Size opAdd(Size sz)
	{
		Size result;
		result.width = width + sz.width;
		result.height = height + sz.height;
		return result;
	}
	
	
	///
	Size opSub(Size sz)
	{
		Size result;
		result.width = width - sz.width;
		result.height = height - sz.height;
		return result;
	}
	
	
	///
	void opAddAssign(Size sz)
	{
		width += sz.width;
		height += sz.height;
	}
	
	
	///
	void opSubAssign(Size sz)
	{
		width -= sz.width;
		height -= sz.height;
	}
***********************end*************************
 if the type of width and height  are size_t,then their values will be error.


small test:
-----------------------
import std.stdio;

void main()
{
	size_t width = 10;
	size_t height = 20;
	writeln("before width is ",width," ,height is ",height);
    height -= 1;
    width -= height;
    writeln("after width is ",width," ,height is ",height);
}
----------
"after width is " ERROR.

On Thursday, 20 November 2014 at 13:26:23 UTC, FrankLike wrote:
>
>>> auto x = foo();
>>> auto y = bar();
>>> auto z = baz();
>>>
>>> if (x - y > z) { ... }
>>>
>>>
>>> This might be a bug, if one of these functions returns an unsigned
>>> type.  Good luck finding that. Note that if all functions return
>>> unsigned, there isn't even any signed-unsigned mismatch.
>>>
>>> I believe the correct statement, is "With only a bit of care one can use
>>> D's unsigned types for positive numbers and believe that one's code is
>>> correct, even though it contains subtle bugs."
>>
>> Well I'm sorry but I quite disagree. -- Andrei
>
> This might be a bug.
>
> 'Length' always needs to compare sizes. 'Width' and 'Height' like it.
>
> ************************ dfl/drawing.d line:185 -218 **************************
>
> 	///
> 	Size opAdd(Size sz)
> 	{
> 		Size result;
> 		result.width = width + sz.width;
> 		result.height = height + sz.height;
> 		return result;
> 	}
> 	
> 	
> 	///
> 	Size opSub(Size sz)
> 	{
> 		Size result;
> 		result.width = width - sz.width;
> 		result.height = height - sz.height;
> 		return result;
> 	}
> 	
> 	
> 	///
> 	void opAddAssign(Size sz)
> 	{
> 		width += sz.width;
> 		height += sz.height;
> 	}
> 	
> 	
> 	///
> 	void opSubAssign(Size sz)
> 	{
> 		width -= sz.width;
> 		height -= sz.height;
> 	}
> ***********************end*************************
>  if the type of width and height  are size_t,then their values will be error.
>
>
> small test:
> -----------------------
> import std.stdio;
>
> void main()
> {
> 	size_t width = 10;
> 	size_t height = 20;
> 	writeln("before width is ",width," ,height is ",height);
>     height -= 1;
>     width -= height;
>     writeln("after width is ",width," ,height is ",height);
> }
> ----------
> "after width is " ERROR.

I get "after width is 18446744073709551607 ,height is 19", which looks mathematically correct to me.

On 11/20/14, 6:47 AM, Andrei Alexandrescu wrote:
> On 11/20/14 12:18 AM, Don wrote:
>> On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu
>> wrote:
>>> On 11/19/14 6:04 AM, Don wrote:
>>>> Almost everybody seems to think that unsigned means positive. It does
>>>> not.
>>>
>>> That's an exaggeration. With only a bit of care one can use D's
>>> unsigned types for positive numbers. Please let's not reduce the
>>> matter to black and white.
>>>
>>> Andrei
>>
>> Even in the responses in this thread indicate that about half of the
>> people here don't understand unsigned.
>>
>> "unsigned" means "I want to use modulo 2^^n arithmetic". It does not
>> mean, "this is an integer which cannot be negative".
>>
>> Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to
>> represent a non-negative integer, you are using the incorrect type.
>>
>>> "With only a bit of care one can use D's unsigned types for positive
>>> numbers."
>>
>> I do not believe that that statement to be true. I believe that bugs
>> caused by unsigned calculations are subtle and require an extraordinary
>> level of diligence. I showed an example at DConf, that I had found in
>> production code.
>>
>> It's particularly challenging in D because of the widespread use of
>> 'auto':
>>
>> auto x = foo();
>> auto y = bar();
>> auto z = baz();
>>
>> if (x - y > z) { ... }
>>
>>
>> This might be a bug, if one of these functions returns an unsigned
>> type.  Good luck finding that. Note that if all functions return
>> unsigned, there isn't even any signed-unsigned mismatch.
>>
>> I believe the correct statement, is "With only a bit of care one can use
>> D's unsigned types for positive numbers and believe that one's code is
>> correct, even though it contains subtle bugs."
>
> Well I'm sorry but I quite disagree. -- Andrei
>

I don't think disagreeing without a reason (like the one Don gave above) is good.

You could show us the benefits of unsigned types over signed types (possibly considering that not every program in the world needs an array with 2^64 elements).