size_t index=-1;

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/21/16 4:27 PM, tsbockman wrote:
> On Monday, 21 March 2016 at 17:38:35 UTC, Steven Schveighoffer wrote:
>> Your definition of when "implicit casting is really a bad idea" is
>> almost certainly going to include cases where it really isn't a bad idea.
>
> This logic can be applied to pretty much any warning condition or
> safety/correctness-related compiler feature; if it were followed
> consistently the compiler would just always trust the programmer, like
> an ancient C or C++ compiler with warnings turned off.

Right, if we were starting over, I'd say let's make sure you can't make 
these kinds of mistakes. We are not starting over though, and existing 
code will have intentional uses of the existing behavior that are NOT 
bugs. Even that may have been rejected by Walter since a goal is making 
C code easy to port.

Note that we already have experience with such a thing: if(arr). Fixing 
is easy, just put if(arr.ptr). It was rejected because major users of 
this "feature" did not see any useful improvements -- all their usages 
were sound.

>> The compiler isn't all-knowing, and there will always be cases where
>> the user knows best (and did the conversion intentionally).
>
> That's what explicit casts are for.

Existing code doesn't need to cast. People are lazy. I only would insert 
a cast if I needed to. Most valid code just works fine without casts, so 
you are going to flag lots of valid code as a nuisance.

>> An obvious one is:
>>
>> void foo(ubyte[] x)
>> {
>>   int len = x.length;
>> }
>>
>> (let's assume 32-bit CPU) I'm assuming the compiler would complain
>> about this, since technically, len could be negative! Disallowing such
>> code or requiring a cast is probably too much.
>
> But that *is* a bad idea - there have been real-world bugs caused by
> doing stuff like that without checking.

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.

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

-Steve