Why is `scope` planned for deprecation?

[via Digitalmars-d]

On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
> On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
> Grøstad wrote:
>> 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.

I think it can happen. D needs a new intermediate layer where you 
can do global flow analysis.

compile src -> ast -> partial evaluation -> high level IR -> disk

instantiate high level IR -> intermediate IR -> disk

global analysis over  intermediate IR

intermediate IR -> LLVM -> asm

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

>> 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. I think region 
allocators do better if you start constraining relations by 
ownership.

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

D need to appropriate what C++ has and do it better. Basically it 
means integrating GC pointers with unique_ptr and shared_ptr.

If D is going to be stuck on what it has and "fix" it with addig 
crutches it will go nowhere, and C++ will start to look like a 
better option…