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
