On 11/19/14 12:38 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> No. -- Andrei
>
> Yet, experience in D has shown very well that having unsigned lengths is
> the wrong design choice. It's a D wart.

Care to back that up? -- Andrei

On 11/19/14 12:40 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> There are related bugs in Java too, e.g. I remember one in binary
>> search where (i + j) / 2 was wrong because of an overflow.
>
> This is possible in D too.
>
>
>> Also, Java does have a package for unsigned integers so apparently
>> it's necessary.
>
> This is irrelevant. No one here is saying that a system language should
> not have unsigned values. The discussion here is about the type of array
> lengths.

I think we're in good shape with unsigned. -- Andrei

On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 11/19/14 12:40 PM, bearophile wrote:
> >Andrei Alexandrescu:
> >
> >>There are related bugs in Java too, e.g. I remember one in binary search where (i + j) / 2 was wrong because of an overflow.
> >
> >This is possible in D too.
> >
> >
> >>Also, Java does have a package for unsigned integers so apparently it's necessary.
> >
> >This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
> 
> I think we're in good shape with unsigned. -- Andrei

Implicit conversion between signed/unsigned is the fly that spoils the soup, and the source of subtle bugs that persistently crop up when dealing with size_t. The fact of the matter is that humans are error-prone, even when they are aware of the pitfalls of mixing signed / unsigned types, and currently the language is doing nothing to help prevent these sorts of mistakes.


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble again.

On 11/19/14 4:24 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 11/19/14 12:40 PM, bearophile wrote:
>>> Andrei Alexandrescu:
>>>
>>>> There are related bugs in Java too, e.g. I remember one in binary
>>>> search where (i + j) / 2 was wrong because of an overflow.
>>>
>>> This is possible in D too.
>>>
>>>
>>>> Also, Java does have a package for unsigned integers so apparently
>>>> it's necessary.
>>>
>>> This is irrelevant. No one here is saying that a system language
>>> should not have unsigned values. The discussion here is about the
>>> type of array lengths.
>>
>> I think we're in good shape with unsigned. -- Andrei
>
> Implicit conversion between signed/unsigned is the fly that spoils the
> soup, and the source of subtle bugs that persistently crop up when
> dealing with size_t. The fact of the matter is that humans are
> error-prone, even when they are aware of the pitfalls of mixing signed /
> unsigned types, and currently the language is doing nothing to help
> prevent these sorts of mistakes.

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

> How is that a bug? Can you provide some code that exhibits this?

If you compile the dfl Library to 64 bit,you will find error:

core.sys.windows.windows.WaitForMultipleObjects(uint
nCount,void** lpHandles,....) is not callable using argument
types(ulong,void**,...)

the 'WaitForMultipleObjects' Function is in
dmd2/src/druntime/src/core/sys/windows/windows.d

the argument of first is dfl's value ,it comes from a 'length'
,it's type is size_t,now it is 'ulong' on 64 bit.

So druntime must keep the same as  phobos for size_t.
Or  keep the same to int with WindowsAPI to  modify the size_t to int ?

On Wed, Nov 19, 2014 at 04:42:53PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 11/19/14 4:24 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> >>On 11/19/14 12:40 PM, bearophile wrote:
> >>>Andrei Alexandrescu:
> >>>
> >>>>There are related bugs in Java too, e.g. I remember one in binary search where (i + j) / 2 was wrong because of an overflow.
> >>>
> >>>This is possible in D too.
> >>>
> >>>
> >>>>Also, Java does have a package for unsigned integers so apparently it's necessary.
> >>>
> >>>This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
> >>
> >>I think we're in good shape with unsigned. -- Andrei
> >
> >Implicit conversion between signed/unsigned is the fly that spoils the soup, and the source of subtle bugs that persistently crop up when dealing with size_t. The fact of the matter is that humans are error-prone, even when they are aware of the pitfalls of mixing signed / unsigned types, and currently the language is doing nothing to help prevent these sorts of mistakes.
> 
> 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.
[...]

Actually, I agree about using unsigned for object lengths. I think it's a sound decision -- why use a signed value for something that can never be negative?

OTOH, what spoils this (hence the fly in soup reference), is the fact that you can now take these unsigned values and randomly mix them up with signed values without a single warning from the compiler. Even requiring a cast to signify "I know what I'm doing, just do as I say" would be an improvement over the current silent acceptance of questionable code like `if (x.length - y.length < 0) ...`.


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom

On Wednesday, 19 November 2014 at 20:38:15 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> No. -- Andrei
>
> Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart.
>
> Bye,
> bearophile

Yet, MY experience in D has shown very well that having unsigned
lengths is the RIGHT design choice. It's NOT a D wart.

On Thursday, 20 November 2014 at 00:07:23 UTC, Andrei Alexandrescu wrote:
> On 11/19/14 12:38 PM, bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> No. -- Andrei
>>
>> Yet, experience in D has shown very well that having unsigned lengths is
>> the wrong design choice. It's a D wart.
>
> Care to back that up? -- Andrei

Don mentioned troubles with that at DConf.

On Thu, Nov 20, 2014 at 01:00:00AM +0000, flamencofantasy via Digitalmars-d wrote:
> On Wednesday, 19 November 2014 at 20:38:15 UTC, bearophile wrote:
[...]
> >Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart.
> >
> >Bye,
> >bearophile
> 
> Yet, MY experience in D has shown very well that having unsigned lengths is the RIGHT design choice. It's NOT a D wart.
[...]

I concur.

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. ;-)


T

-- 
MAS = Mana Ada Sistem?

On 11/19/14, 9:54 PM, FrankLike wrote:
>> How is that a bug? Can you provide some code that exhibits this?
>
> If you compile the dfl Library to 64 bit,you will find error:
>
> core.sys.windows.windows.WaitForMultipleObjects(uint
> nCount,void** lpHandles,....) is not callable using argument
> types(ulong,void**,...)
>
> the 'WaitForMultipleObjects' Function is in
> dmd2/src/druntime/src/core/sys/windows/windows.d
>
> the argument of first is dfl's value ,it comes from a 'length'
> ,it's type is size_t,now it is 'ulong' on 64 bit.
>
> So druntime must keep the same as  phobos for size_t.
> Or  keep the same to int with WindowsAPI to  modify the size_t to int ?

Sorry, maybe I wasn't clear. I asked "how a negative length can be a bug".

(because you can't set a negative length, so it can't really happen)