When is it time for a 1.0 feature freeze?

[Sean Kelly]

Serg Kovrov wrote:
> * Ivan Senji:
>> I don't have anything against D1.1 od D1.5 or even D2.0 having these 
>> features but I am a little worried about what happens when D1.0 
>> attracts new people and they must very quickly realize "what? D 
>> doesn't have array and struct literals? What kind of a language is that?"
> 
> I'm more concerning about memory management scheme.
> 
> Most people I was talking to about D (and I agitate very fellow 
> programmer i personally know to at least try D)... firstly complains 
> about 'yet another language' syndrome. There is really nothing can be 
> done about it, you just have to convince them to not to stop discussion =)
> 
> Next, everyone from C/C++ camp (especially C) is just so-skeptical about 
> GC. All sort of things were already beaten to death here on NG. It is a 
> meter of personal taste and there is nothing can't be done either.
> 
> And then usually happens following: on my clumsy allegations that it is 
> not necessary to use GC, and with malloc/free one could manage memory 
> manually. Well, you know... Whom I trying to deceive, myself? It is 
> simply not so convenient to actually do so. And what about string 
> operations (concatenations, assignment etc), they use GC and i don't 
> know how to avoid it.

The same as you would in C.  Manually allocate and free the buffer 
referenced by the array ptr.  The layout of dynamic arrays is specified 
in the ABI, so you're guaranteed to have a .len and .ptr property to 
play with if you really want to.

 > Plus, standard library is hard-coupled with GC.

It doesn't have to be.  That's just how Phobos was written.

 > My
> point is that if not use GC programming with D is even more awkward then 
> C/C++.

True.  Though I think 'scope' statements help a lot, and stack 
allocation will help tremendously.  Walter has already said he plans to 
implement:

   MyClass c = new MyClass(); // heap alloc
   MyClass d = MyClass();     // stack alloc

And hopefully:

   char[] a = new char[32]; // heap alloc
   char[] b = char[32];     // stack alloc

This would do away with the need for alloca(), which would conflict with 
dynamic closures anyway.  An in-language solution, however, may be 
compatible in some cases.

> But that not worst part. Although I'm personally from C++ camp and I get 
> used to GC. and see it as good thing. But, there is one big BUT! 
> Currently GC do not return memory to OS, and that thing even I can't 
> subdue.

This is just the default GC shipped with DMD (and GDC).  There's no 
reason it can't be replaced.  In fact, I've taken steps to make this as 
easy as possible in Ares.

> Most desktop applications (like text editors, news readers, web 
> browsers, etc) must coexist with each other. That is, to use memory 
> wisely and give it back if it not needed anymore. This 'upper water 
> mark' approach in GC is just not acceptable.

I think it depends on the application.  If an application behaves 
consistently across their run cycle, there's no reason to return memory 
to the OS because it will likely be needed again.  If an application 
allocates a ton of memory, frees it, and never uses it again then what 
you say is true.  Though in these cases the application could call 
malloc/free for these one-time memory allocations as well.

> All I actually can say to my fellow programmers in defense of D, is that 
> language still developing and eventually all good things happens. On 
> that point discussion usually ends and the bottom line is "nice 
> language, we will look at later, when/if it evolve".

I think it's important to separate discussions of the language with the 
behavior of accompanying library code.  The GC occupies kind of a 
strange middle-ground here, but I still consider it library code because 
nothing inside is required to be compiler-specific.  Sure the compiler 
runtime allocates and frees memory, but it doesn't need special access 
that is not available to the user.  Personally, I think D as a language 
is shaping up quite nicely.  The library could perhaps use a little 
work, but that can be done without changing the language spec.


Sean