Disallow arrays as pointers

[Timon Gehr]

On 10/31/2011 12:03 AM, bearophile wrote:
> Jonathan M Davis:
>
>> from what I understand,
>> it's quite common for D programmers interacting with C code to just pass
>> arrays to C functions without using the ptr property.
>
> That code works with an implicit conversion that saves the typing of 4 more chars, while introducing something that is negative for both newbie D programmers and more trained ones. ".ptr" was introduced in D to avoid this.
>
> In general I find it curious that D design tries to avoid some mistakes of the C design, and to disallow some bug-prone features of C, like some implicit type conversions.
> But then, it seems that D doesn't take a lot of care to avoid bug-prone "features" that it has introduced, that were not present in C (like the one discussed here, like lax management of strings that represent operators of operator overloading, etc.)
>

I have never had a bug because of arrays implicitly converting to 
pointers. I'd sometimes even like e.g. ++array to mean 
array=array[1..$]. A lot of C's carefully designed syntactic elegance is 
lost when going from pointers/iterators to arrays and ranges. But why is 
*array not bounds checked in non-release mode? I think it should be.

The lax management of strings is not a bug-prone feature. (in the sense 
that it would be likely to produce erroneous code because of subtle 
typing mistakes.) Sure, if the implementer of the aggregate using 
operator overloading does not handle invalid sequences, it can be 
"exploited" to gain access to private members and/or implementation 
details. That does not happen by accident.
I don't think Phobos helps enough to make correct handling easy, maybe 
some simple isOpBinary(string), isOpUnary(string), etc. templates would 
be worth adding.