Isn't it about time for D3?

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 15 June 2017 at 17:06:31 UTC, Sebastien Alaiwan 
wrote:
> On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
>> Should D really move to GC-free? I think there is already 
>> enough GC-free language on the market. D even now is very 
>> complected language, and adding ways to manually managing 
>> memory will make it's more complicated.
>
> We need automatic deterministic destruction (and we partially 
> have it, using scope(exit) and structs RAII).

Not sure what exactly you are expecting, tbh. If you expect 
classes to be changed to behave like structs with regards to 
finalization: That can't happen, because they are reference 
types, not value types:
The lifetime of value type objects is statically known to end at 
their enclosing scope (unless they are moved), in contrast to 
reference types.

>
> Memory management is only the tip of the iceberg of resource 
> management ;it's the easy problem, where an automated process 
> can to tell which resources aren't needed any more.
>
> However, an instance of a class can hold a lot more than flat 
> memory blocks: threads, file handles, on-disk files, 
> system-wide events, sockets, mutexes, etc.

All of which you can easily take care of in the class' destructor 
and then .destroy such objects when needed.

>
> Freeing the memory of my "TcpServer" instance is mostly useless 
> if I can't reinstanciate a new one because the TCP port is kept 
> open by the freed instance (whose destructor won't be run by 
> the GC).

*might not be run by the GC when you want it to.

Why are you even talking about the GC when your problem seems to 
require deterministic lifetime management. That's not what a GC 
does, and thus it's the wrong tool for the job.
The right tool here would be one of
- std.experimental.allocator.{make,dispose} (statically known 
lifetime)
- {std.typecons / automem}.RefCounted (dynamic lifetime)