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

[Tom]

Another vote.

--
Tom;

Oskar Linde wrote:
> 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