D loosing the battle

[gzp]

I've been following D for a while, and I've lost some of my interest too 
for several reasons.

   The continuous redesign. When I started to implement s/g, I checked 
what opportunities I have, what the language specification tells, and 
what others did to achieve a similar goal. Then I implemented my own 
version, but by the time I was almost finished, I saw some major 
features are being altered. (scope - allocation, Ranges, operator 
overloading, struct constructors, array referencing, property, etc.). I 
know D is a language being developed, but when core functionality is 
being altered all the time, it's really hard to design/implement new 
libraries. At least D users (especially for newbies) should be informed 
of the state of the progress, not only through mailing list since the 
have lot's of proposals those are dropped immediately. ex: The language 
reference should be up to date as much as possible and *HILIGHT* the 
features being redesigned and what are the proposals (in 1-2 words). I'm 
sure Walter, Andrei, and the other (key) developers have a todo-list 
(and some time-tables) for the proposed modifications. (If no, D is 
Doomed for sure, since after a while no one knows what's finished and 
what is still to be implemented, and what was the planned feature)

For example, some time back, there was a proposal about altering the 
property. There`s also been a voting, but now there's no sign of this 
anywhere (except for the forum).
I liked the property idea a lot, but I cannot use it, i cannot even 
design my code to later update it using properties as there's no sign of 
its currnet state.
I know the current property implementation is based on omitting the () 
signs, but I'm not using it, as it was meant to be changed, but when and 
how ???
The same stands for the scoped variables. I've started to use it to 
allocate class instances of (small)matrices on the stack, but than i've 
read, it will go. So I have to redesign things to use structs instead of 
classes to have them on the stack, but using struct requires other type 
of initialization mechanism, as they have no default constructor to 
overload. And now the construction of the struct is being altered as 
well. And so on...

I don't require a language with all the features completed, but altering 
the core features makes it impossible to create new/stable libraries.
I can go quite well without the opPow, and other operator overloading 
stuffs. I will update the library if they are present in the language 
and call the my appropriate function ( 1+2 additional lines to the 
source) but how to design anything if basic semantics are changing ?!

   Lack of IDE (minor issue). It's not a big problem, actually I can go 
quite well without an IDE, or without a debugger either (good old 
printf:) in most cases. (I've seen there were made great progresses in 
this as well)

   Missing stable, compiler with enhanced optimization features (minor 
issue). I've tried to reimplement some of my older algorithm from c++, 
but finally I haven't even tried most of them, as I didn't see any 
optimization in the asm codes for my simplest range. (The popFront, 
front, empty function calls were not inlined at all - though i didn't 
experienced with it too much as I could not find an appropriate 
IDE/debugger to check the asm code and insert breakpoints)
I've tried to use gdc, but it only superts D1. The patch/branch to use 
D2 i have to be built manually. I don't want to compile, patch, etc. a 
C/C++ project from some unstable source and work for hours to have a
working D compiler. I want to do D.

So for these reason I'm in a passive state and i'm waiting where D goes 
to. According to my oppinion there are many other programmars following 
D in a passive way like I do.
I like many features of D (and dislike some - but it's ok, cannot have a 
language that fits all the desires for everybody ), but while it's in a 
so mutable state, it`s hard to use it. I have to wait while most 
features are made immutable (and not const, that can be altered through 
some nasty const_cast proposals :) ).

Regards,
	Gzp