Disadvantages of building a compiler and library on top of a specific memory management scheme

[Frustrated]

On Thursday, 6 February 2014 at 18:44:49 UTC, fra wrote:
> On Thursday, 6 February 2014 at 18:18:49 UTC, Andrei 
> Alexandrescu wrote:
>> On 2/6/14, 9:54 AM, Frustrated wrote:
>>> {
>>> auto a = new!strategy A;
>>>
>>> // implicit deallocation: compiler inserts
>>> strategy.scopeDeallocation(a);
>>> }
>>
>> I don't think this works. The scope of "strategy" and "a" may 
>> be unrelated. More importantly a may be escaped (e.g. by 
>> passing it to functions etc) unbeknownst to "strategy", which 
>> in fact suggests that the strategy must be somehow known by 
>> "a" independently.
> Perhaps he meant doing something like: this refence dies here, 
> control of the object is now passed to the "Strategy Manager", 
> that could be a reference counter that decreases its counter, 
> the GC that takes care of everything, and so on.

Yes,

ScopeDeallocation would either be nop for manual allocation or a
decrements of a reference counter.

For example, if you were using manual allocation but backed by
ARC or GC then scopeDeallocation would actually do something. If
you wanted completely control then it could be a nop or a warning.

Basically have the compiler fill in all the missing information
that it can in "implicit calls" to the strategy method. These
could be "overridden" to do whatever one wants depending on what
the goal is. If an explicit call is made then the compiler won't
add the implicit call.