On 11/20/14 7:40 AM, Araq wrote:
> It's not only his "opinion", it's his *experience*

Yes, there's some good anecdotal evidence too. IMHO not enough to trigger a change to other solutions that have their own issues. -- Andrei

On Thursday, 20 November 2014 at 08:18:24 UTC, Don wrote:
> ...
>
> 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 personally think this code is bad style. If the function requires a signed integer type, then `auto` with no qualifications at all is clearly too loose- if the programmer had specified what he needed to begin with, the error would have been caught at compile time.

You can replace `auto` with an explicit signed integer type like `long`. If foo and bar are template parameters and you don't know the precise return type, then a static assert that x and y are signed will do the trick.

If it is known that x > y and the function does not require a signed integer type, then an assert should be used.

Frankly that snippet just illustrates the sort of constraints that should be put on generic code.

On Thursday, 20 November 2014 at 15:55:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
> Using unsigned types for array length doesn't necessarily lead to subtle
> bugs, if the language was stricter about mixing signed and unsigned
> values.
>

Yes, I think that this is the real issue.

On 11/20/2014 6:22 AM, Ary Borenszweig wrote:
> Nobody is saying to remove unsigned types from the language. They have their
> uses. It's just that using them for an array's length leads to subtle bugs.
> That's all.

If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs, plus you'll break the intuition about these things from everyone who has used C/C++ a lot.

On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
> What *could* be improved, is the prevention of obvious mistakes in
> *mixing* signed and unsigned types. Right now, D allows code like the
> following with no warning:
>
> 	uint x;
> 	int y;
> 	auto z = x - y;
>
> BTW, this one is the same in essence as an actual bug that I fixed in
> druntime earlier this year, so downplaying it as a mistake people make
> 'cos they confound computer math with math math is fallacious.

What about:

    uint x;
    auto z = x - 1;

?

Walter Bright:

> If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs,

This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.

Bye,
bearophile

> What about:
>
>     uint x;
>     auto z = x - 1;
>
> ?

When mixing signed and unsigned, as signed, it maybe no mistaken.

thhere is a small test,add 'cast(long)' before - operator,if it's auto add,maybe fine.
-----

import std.stdio;

void main()
{
	size_t width = 10;
	size_t height = 20;
	writeln("before width is ",width," ,height is ",height);
    height -= 15;
    width -=  cast(long)height;
    writeln("after width is ",width," ,height is ",height);
}
----result: after width is 5 .
it's ok.

Frank

On 11/20/2014 3:25 PM, bearophile wrote:
> Walter Bright:
>
>> If that is changed to a signed type, then you'll have a same-only-different
>> set of subtle bugs,
>
> This is possible. Can you show some of the bugs, we can discuss them, and see if
> they are actually worse than the current situation.

All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.

On 11/20/2014 3:37 PM, FrankLike wrote:
>
>> What about:
>>
>>     uint x;
>>     auto z = x - 1;
>>
>> ?
>
> When mixing signed and unsigned, as signed, it maybe no mistaken.

I think you missed my question - is that legal code under H.S.Teoh's proposal?

On 11/19/2014 8:22 AM, David Gileadi wrote:
> 2. That there's a need for it at all, which requires knowing that length is
> unsigned. I did know this, but I bet in the heat of programming I'd easily
> forget it. In a semi-complex algorithm the bug could easily hide for a long time
> before biting.

If it was signed, you'd just have different issues hiding.