size_t index=-1;

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/21/16 7:43 PM, tsbockman wrote:
> On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer wrote:
>> It depends on the situation. foo may know that x is going to be short
>> enough to fit in an int.
>>
>> The question becomes, if 99% of cases the user knows that he was
>> converting to a signed value intentionally, and in the remaining 1% of
>> cases, 99% of those were harmless "errors", then this is going to be
>> just a nuisance update, and it will fail to be accepted.
>
> My experimentation strongly suggests that your "99.99% false positive"
> figure is way, *way* off. This stuff is both:

Maybe, what would be a threshold that people would find acceptable?

> 1) Harder for people to get right than you think (you can't develop good
> intuition about the extent of the problem, unless you spend some time
> thoroughly auditing existing code bases specifically looking for this
> kind of problem), and also

It matters not to the person who is very aware of the issue and doesn't 
write buggy code. His code "breaks" too.

I would estimate that *most* uses of if(arr) in the wild were/are 
incorrect. However, in one particular user's code *0* were incorrect, 
even though he used it extensively. This kind of problem is what lead to 
the change being reverted. I suspect this change would be far more 
likely to create more headaches than help.

> 2) Easier for the compiler to figure out than you think - I was really
> surprised at how short the list of problems flagged by the compiler was,
> when I tested Lionello Lunesu's work on the current D codebase.

This is highly subjective to whose code you use it on.

> The false positive rate would certainly be *much* lower than your
> outlandish 10,000 : 1 estimate, given a good compiler implementation.

I wouldn't say it's outlandish given my understanding of the problem. 
The question is, does the pain justify the update? I haven't run it 
against my code or any code really, but I can see how someone is very 
good at making correct uses of the implicit conversion.

>>> With respect to your specific example:
>>>
>>> 1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with
>>> an OS that reserves some of the address space, as much as 3GiB or 3.5GiB
>>> may be exposed to a user-space process in practice.
>>
>> Then make it long len = x.length on a 64-bit system.
>>
>> Only reason I said assume it's 32-bit, is because on 64-bit CPU, using
>> int is already an error. The architecture wasn't important for the
>> example.
>
> Huh? The point of mine which you quoted applies specifically to 32-bit
> systems. 32-bit array lengths can be greater than `int.max`.
>
> Did you mean to reply to point #3, instead?

You seem to spend a lot of time focusing on 32-bit architecture, which 
was not my point at all.

My point is that most arrays and uses are short enough to be handled 
with a signed value as the length.

If this is a generic library function, sure, we should handle all 
possibilities. This doesn't mean someone's command line utility 
processing strings from the argument list should have to worry about 
that (as an example). Breaking perfectly good code is something we 
should strive against.

-Steve