Article about problems & suggestions for D 2.0

[Mehrdad]

On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
> After having used the D 2.0 programming language for a year now and 
> having completed 3 projects with it, I wrote a small article about the 
> problems I had with the D 2.0 programming language and what 
> suggestions I have to improve it.
>
> http://3d.benjamin-thaut.de/?p=18
>
> Comments and criticism welcome
>
 > "This transitiv[it]y basically kills you everywhere."

I feel like you hit the nail on the head. I feel the same way about const.

Transitivity is beautiful on the outside, but I can never actually get 
it working, so I just make everything non-const. I have to sometimes do 
this even in Phobos itself, because the compiler complains about 
something random caused by transitivity.
I also fail to see what /problem/ it's trying to solve. The DigitalMars 
website simply states:

"With transitivity, there is no way to have a const pointer to mutable int."

But... so what? Maybe it should actually explain the benefit, since I 
can't figure it out on my own. (The related discussion on "head-const" 
and "tail-const" seems completely irrelevant to the topic."

C++'s non-transitivity seems to be quite type-safe, even if unintuitive 
to the beginner (which I don't think it is). I *never* ran into issues 
with it.


*On the bright side*, I LOVE immutable. It's one of the best features of 
D, IMO. (Or at least it would be, if only it /wasn't/ transitive.) I 
don't like the way C++ mixes the idea of "this never mutates" versus 
"YOU can't mutate this object", and I feel like D was really smart in 
making the distinction between the two.


Related suggestion: All methods that return /new/ strings should return 
*mutable* arrays. There's really no reason (that I can think of) to not 
do this: if you see something returning a mutable array, you _know_ it's 
a new array (unless otherwise documented), so you _know_ it's safe to 
cast it to immutable if needed. It doesn't work the other way around, 
though.