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.
