An Issue I Wish To Raise Awareness On

[Atila Neves via Digitalmars-d]

On Friday, 21 July 2017 at 11:57:11 UTC, Kagamin wrote:
> On Friday, 21 July 2017 at 08:51:27 UTC, Atila Neves wrote:
>> Mutexes and sockets are classes, so not destroyed 
>> deterministically.
>
> They should, like any unmanaged resources, e.g. by wrapping in 
> a smart pointer. Imagine 10000 lingering tcp connections 
> accumulated over time due to poor timing of destruction, it 
> becomes a stress test for the server.
>
>> Anything that is `shared` is likely to be a reference 
>> (pointer, class...), or a global. Either way the 
>> compiler-generated destructor call isn't going to exist, which 
>> means it's probably ok to cast away shared when the compiler 
>> inserts the automatic call to a destructor at the end of scope.
>
> These are contradictory. Does the automatic destructor call 
> exist or not?

What I'm trying to say is that `shared` values will usually be 
references or globals and therefore there won't be a 
compiler-generated call to the destructor at the end of scope.

When the compiler _does_ generate a call to the destructor, the 
value is unlikely to be shared.

Since then I've thought that sending a value to another thread 
does indeed create a shared value with defined scope. Or, for 
that matter, calling any function that takes shared values (but 
those are rare, so it'll usually be `send`).

I think I've not done a good job of explaining the destructor 
fix: what it changes is the code the compiler writes for you when 
variables go out of scope, i.e. the automatic destructor call 
casts away shared. It already did the same thing for immutable, 
otherwise you wouldn't be able to put immutable values on the 
stack.

Atila