Why is `scope` planned for deprecation?

[via Digitalmars-d]

On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:
> On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
> Digitalmars-d wrote:
>> Are you guys saying you don't feel this proposal is practical?
>> http://wiki.dlang.org/User:Schuetzm/scope
>>
>> I think it's a very interesting approach, and comes from a 
>> practical
>> point of view. It solves the long-standings issues, like scope 
>> return
>> values, in a very creative way.
>
> It is better solved using static analysis

You mean without additional hints by the programmer? That's not 
going to happen, realistically, for many reasons, separate 
compilation being one of them.

> and it is part of a bigger problem complex where ref counting 
> should be considered. Otherwise you end up writing N versions 
> of the same code. You want the same interface for GC, 
> shared_ptr, unique_ptr, stack_allocated_data etc. Let the 
> compiler do the checking.

Huh? That's exactly what _borrowing_ does. Ref-counting OTOH adds 
yet another reference type and thereby makes the situation worse.

>
> 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.

> Types that can be owned has to provide release() and move(). 
> That would work for GC, shared_ptr, unique_ptr, but not for 
> stack allocated data:
>
> GC ptr: release() and move() are dummies.
>
> shared_ptr: release() decrements, move() just transfers
>
> unique_ptr: release() destroys, move() transfers
>

For a new language built from scratch, this might make sense. D 
is already existing, and needs to work with what it has.

> D has to stop adding crutches. Generalize!

That's what I'm trying to do with my proposal :-)