why allocators are not discussed here

[BLM768]

On Wednesday, 26 June 2013 at 23:59:01 UTC, Adam D. Ruppe wrote:
> On Wednesday, 26 June 2013 at 23:02:47 UTC, H. S. Teoh wrote:
>> Maybe a type distinction akin to C++'s auto_ptr might help?
>
> It might not be so bad if we modified D to add a lent storage 
> class, or something, similar to some discussions about scope in 
> the past.
>
> These would be values you may work with, but never keep; 
> assigning them to anything is not allowed and you may only pass 
> them to a function or return them from a function if that is 
> also marked lent. Any regular reference would be implicitly 
> usable as lent.

Something along those lines would probably be a good solution.

It seems that we're working with three types of objects:

1. Objects that are "owned" by a scope (can be stack-allocated)
2. Objects that are "owned" by a another object (C/C++-like 
memory management)
3. Objects that have no single "owner" (GC memory management)

The first two would probably operate under semantics like "lent" 
or "scope", although I'd like to propose an extension to the 
rules: it should be possible to store a weak reference to these 
types (or at least to #2) once we have weak reference support.

The third type seems to be pretty much solved, seeing as we have 
a (mostly) working GC.

Something like this might be a nice way to implement it:

class Thing {}

void doSomething(scope Thing t); //Takes #1, #2, or #3 by 
reference
void doSomethingElse(owned Thing t); //Takes only #2 or #3

void main() {
   scope Thing t1; //stack-allocated
   doSomething(t1);
   owned Thing t2 = new Thing; //heap-allocated but freed at end 
of scope
   doSomething(t2);
}