Suggestion: Remove implicit conversion from T[n] and T[] to T*

akcom CppCoder at gmail.com
Fri Dec 1 12:00:16 PST 2006


I was completely unaware that this is done implicitly, I've always used the 
ptr property.  This has my vote as well.
"Oskar Linde" <oskar.lindeREM at OVEgmail.com> wrote in message 
news:ekn8dq$f5t$1 at digitaldaemon.com...
> Removing the implicit conversion from static arrays (T[n]) and dynamic 
> arrays (T[]) to pointers T* may be quite controversial, but would help 
> clear up some problems and feels like the right step to take.
>
> Motivation:
>
> - Implicit conversions are generally bad. There are cases where they make 
> sense, but those need a very good reason.
> - Both conversions are available by the .ptr property already and by using 
> that the code is clearer and more self documenting.
> - T[] contains both a length and a ptr. Both are needed to retain the 
> information. Symmetrically requiring (a.ptr, a.length) makes sense.
> - Decoupling arrays from pointers somewhat lifts D to a slightly higher 
> abstraction level without losing any power.
>
> Case study: Phobos
>
> Phobos contains 150 lines that rely on implicit T[n] and T[] => T* 
> conversions. (Not counting multi-typed string literals that magically 
> bypass the regular conversion rules.)
>
> Of those
>
> 78 lines (52 %) are directly related to calls to C functions. Including:
>    21 s[n]printf
>    20 memcmp
>    17 memcpy
>  Requiring changes such as:
>  - .send(sock, buf, buf.length, cast(int)flags);
>  +      .send(sock, buf.ptr, buf.length, cast(int)flags);
>
> 16 are C-like D function calls, like
>  - writeBlock(bom,bom.length);
>  + writeBlock(bom.ptr, bom.length);
>
> 29 are trivial assignments, like:
>  - ubyte *str = s;
>  +      ubyte *str = s.ptr;
>
> 7 are "new", where this change has a slight negative impact on code:
>  - R = new dchar[Rsize];
>  + R = (new dchar[Rsize]).ptr;
>
> 20 remaining are other minor changes like:
>  -           if (sp != stack)
>  +           if (sp != stack.ptr)
>
> I am very likely to have made some mistakes in this analysis, and missed 
> important cases, but in general, I think most of the changes actually 
> increase the code clarity.
>
> Comments?
>
> /Oskar 





More information about the Digitalmars-d mailing list