DIP69 - Implement scope for escape proof references

[via Digitalmars-d]

On Tuesday, 16 December 2014 at 01:00:47 UTC, Walter Bright wrote:
> On 12/15/2014 5:38 AM, deadalnix wrote:
>> On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
>>> For me "scopeness" is a property of "view", not object itself 
>>> - this also
>>> makes ownership method of actual data irrelevant. Only 
>>> difference between GC
>>> owned data and stack allocated one is that former can have 
>>> scoped view
>>> optionally but for the latter compiler must force it as the 
>>> only available.
>>
>> Ha finally something start to make sense here.
>
> Well, the DIP does defined scope in terms of a 'view' in just 
> this manner.
>
> I am obviously terrible at explaining things.

Don't you think there is a contradiction between this notion of 
"view" and being so focused on lifetimes? Does it make sense to 
explicitly throw away lifetime information and then spend a lot 
of effort on preventing lifetime-violating assignments to take 
place?

The current proposal is either too limiting or not limiting 
enough.

Too limiting, because programmers expect to gain something for 
making parameter types explicit. A naive "make no assumptions 
view" is more suitable as a default, then let the programmer 
specify the specifics where possible/needed, but you need to 
figure out the specifics first and let the "make no assumptions 
view default" be the leftovers…

The proposal is not limiting enough, because retaining knowledge 
about allocation order and aliasing brings important benefits:

An ordered "linear" parameter type would have properties such as:
- being aliasfree
- being on the stack, and cheaply checkable against the stack 
pointer

Sure, ref counting is fairly general for dynamic tracking, but it 
is also quite expensive. A check against the stack-pointer is 
much cheaper.

I think the uncanny valley metaphor that was brought up was quite 
good. If you are going to put in constraints on references, then 
do it in a manner that is easy to deal with and which brings 
benefits such as aliasfree references. If constraints become 
"arbitrary" then usability will suffer and it will seem pointless 
to put in extra work to use them.

You have already gone more or less wholesale for templates, so 
you might as well use it here as well, to bring substantial 
benefits to stack-allocation, because the current proposal is a 
very weak in terms of benefits.