Advice wanted on garbage collection of sockets for c++ programmer using D

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:
> On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis 
> wrote:
>> There are definitely cases where finalizers make sense. Case 
>> in point: if you have a socket class, it makes perfect sense 
>> for it to have a finalizer. Yes, it's better to close it 
>> manually, but it will work just fine for the GC to close it 
>> when finalizing the class object so long as you don't use so 
>> many sockets that you run out before the GC collects them. So, 
>> having a finalizer is a good backup to ensure that the socket 
>> resource doesn't leak.
>>
>> - Jonathan M Davis
>
> So far everyone is ignoring my example when A needs B to be 
> destroyed. This happens as soon as you use DerelictUtil for 
> example.

And I'm gonna rant a little bit more.

Deterministic destruction is a _solved_ problem in C++, and a 
number of users to convert are now coming from C++.

We should:
   1. be honest and tell things as they are: it's more complicated 
than in C++, but also liberating when you know to juggle between 
GC and deterministic
   2. Avoid making bogus suggestions which don't always work, such 
as close() methods, releasing resource with GC, . They only work 
for _some_ resources.
   3. Suggest a systematic, always working, workaround (or 
language change such as "GC doesn't call ~this). C++ users have 
no difficulty having an object graph with detailed ownership 
schemes, that's what they do day in day out.

It's important to have a _simple_ story about resource release, 
else we will talk about "GC" every day, and hearing about "GC" is 
bad for marketing.