Why is `scope` planned for deprecation?

[via Digitalmars-d]

On Thursday, 13 November 2014 at 10:38:57 UTC, Ola Fosheim 
Grøstad wrote:
> On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz 
> wrote:
>> Huh? That's exactly what _borrowing_ does. Ref-counting OTOH 
>> adds yet another reference type and thereby makes the 
>> situation worse.
>
> I don't like explicit ref counting, but it is sometimes useful 
> and I think Rust-style ownership is pretty close to unique_ptr 
> which is ref-counting with a max count of 1… You can also view 
> GC as being implicitly ref counted too (it is "counted" during 
> collection).

I think I understand now how you want to use templates. You 
basically want to make the various reference types implement a 
protocol, and then templatize functions to accept any of those 
reference types, just like we do with ranges.

But this brings with it the downside of templates, namely 
template bloat. And you need to do additional work to eliminate 
all the redundant inc/dec calls if you pass an RC reference. All 
of which is unnecessary for most functions, because a function 
knows in advance whether it needs to retain the reference or just 
borrow it, and can be declared accordingly. This means that 
`scope` acts as an abstraction over the various reference types, 
be it GC, RC, plain pointer, unique pointer, or some more 
complicated user defined scheme.

This also benefits the GC, by the way. A scope reference doesn't 
need to be treated as a root, because there will always be at 
least one other copy of the reference. This means that structures 
containing only scoped references need not be scanned.

>
>>> What does "shared" tell the compiler?
>>
>> I guess you mean "scope"?
>
> :)
>
>>> It tells it "retain no references after completion of this 
>>> function". Like with "pure", it should be opposite. You 
>>> should tell the compiler "I transfer ownership of this 
>>> parameter". Then have a generic concept "owned" for 
>>> parameters that is resolved using templates.
>>
>> That's what deadalnix's proposal does. Though I don't quite 
>> see what templates have to do with it.
>
> My understanding of Deadalnix' proposal is that "owned" objects 
> can only reference other "owned" objects.

Yes. But they can also be merged into un-owned structures (i.e. 
the various heaps), at which point they lose their owned-ness. 
This allows the creator of these objects to be agnostic about how 
the consumers want to handle them.

> I think region allocators do better if you start constraining 
> relations by ownership.

Not sure what you mean, but I don't think region allocators can 
be used for this. They require the object creator to know in 
advance how long the objects will exist. Or alternatively, the 
creators need to be informed about that by receiving a reference 
to the region allocator, at which point we're most likely back at 
templates.