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
