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

[Frustrated]

On Friday, 7 February 2014 at 13:36:12 UTC, Németh Péter wrote:
>
>> It would be more of an abstract type. Something special 
>> template
>> aggregate that the compiler accesses to get code to "hook" in 
>> to
>> the memory management parts of  the code the compiler needs, 
>> but
>> has delegated specifics to the "user".
>
> It's intresting idea for me.
> If we mark a variable with a property, that how that memory is 
> allocated then we got an marked AST node. And based on that 
> mark we can perform AST manipulation during compile time. So if 
> we marked a variable with ARC, then refcount decrease will 
> injected during scope exit. If we mark a variable with GC, 
> nothing will happen. We shoul allocate a separate memory area 
> to refcounts, so that an RC variable can remain a pointer. 
> These are just thoughts, nothing real proposal here... this is 
> on my mind now..

Well, if one is providing hooks and provides the appropriate
hooks then whatever strategy is used defines how it deals with it
all.


Basically the idea is to export the memory management work to
external user code so it can be easily changed. In this case, for
the most part, the compiler will not know that reference counting
is be used(since it might not be) but scope hooks(or callbacks)
need to be used where reference counting would need them.