size_t index=-1;

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/18/16 7:48 PM, tsbockman wrote:
> On Friday, 18 March 2016 at 14:51:34 UTC, Steven Schveighoffer wrote:
>> Note, I have made these mistakes myself, and I understand what you are
>> asking for and why you are asking for it. But these are bugs. The user
>> is telling the compiler to do one thing, and expecting it to do
>> something else. It's not difficult to fix, and in fact, many lines of
>> code are written specifically to take advantage of these rules. This
>> is why we cannot remove them. The benefit is not worth the cost.
>
> Actually, I think I confused things for you by mentioning to `cast(ulong)`.
>
> I'm not asking for a Java-style "no unsigned" system (I hate that; it's
> one of my biggest annoyances with Java). Rather, I'm picking on
> *implicit* conversions between signed and unsigned.

No, I understood you meant implicit casting.

>
> I'm basically saying, "because information is lost when casting between
> signed and unsigned, all such casts should be explicit". This could make
> code rather verbose - except that from my experiments, with decent VRP
> the compiler can actually be surprisingly smart about warning only in
> those cases where implicit casting is really a bad idea.

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. The compiler isn't all-knowing, and there will always be cases 
where the user knows best (and did the conversion intentionally).

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.

-Steve