Why is `scope` planned for deprecation?

via Digitalmars-d digitalmars-d at puremagic.com
Thu Nov 13 02:00:08 PST 2014


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

What does "shared" tell the compiler? 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. 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

D has to stop adding crutches. Generalize!


More information about the Digitalmars-d mailing list