DIP69 - Implement scope for escape proof references

[Dicebot via Digitalmars-d]

On Monday, 15 December 2014 at 06:12:05 UTC, Walter Bright wrote:
> C++ seems to do fine without it for const. It's a convenience 
> feature.

C++ const does not really restrict or affect anything "for real", 
it is non-existent feature. `scope` as proposed would result in 
inability to store result of predicates if those are ever to 
accept scope data - unless you defined two versions for each 
function that may possibly accept scope data with absolutely 
identical body.

>>> 2. This is what scope inference is all about.
>>
>> Which only works with templates and lack of scope on arguments 
>> does not affect
>> function body -> templates are not necessary, same as inout.
>
> It also works with all the lambdas, since source for them is 
> always available. I also wanted to make it (i.e. inference) 
> work with auto functions, but Don Clugston was the primary 
> objector :-)

This is not really answering my objections but side-stepping. I 
do support attribute inference. I would actually support full 
attribute inference in the language (and help convincing Don 
about it ;)) if it was introduced as foundation of the language 
and not arbitrary hack (== rethink the way .di interfaces and 
static libraries are defined)

> I do view inference as something we need to extend to more 
> functions.

That would help with many issues but it need careful design to be 
well-accepted. How about teaming up to do a DIP about it at some 
point where this discussion is over? :P

>>>> 2) at least optional transitivity to be able to express to 
>>>> protect with scope
>>>> data referenced by slice or owned linked list referenced 
>>>> from root node.
>>>
>>> 1. that won't work unless scope is a type constructor
>>
>> I know and this is why I am leaning toward it being qualifier 
>> despite all
>> related issues.
>
> That would be a truly massive change to D, and I'm not at all 
> sure it would be worth it. We've (i.e. Kenji) have been fixing 
> bugs with inout for years, and idea that had seemed 
> straightforward.

Yes, I know and this why I am leaning towards that path but 
willing to accept any storage-class based solution - as long as 
it fits my basic criteria. I wonder if some hybrid approach is 
possible - for example, keep it storage class but pretend 
anything transitively accessible though it as if it was of scope 
storage class on its own. But that quickly gets into "exceptions 
for special cases" land :(

>>> 2. it can be achieved by using wrappers that only allow 
>>> by-scope references to
>>> their data (RC is an example of such a wrapper)
>> It is viral approach and backwards incompatible one - we can't 
>> change signatures
>> of Phobos functions to return Wrapped!(char[]) instead of 
>> char[] for example.
>> While theoretically possible I can't call this approach 
>> practical - not until
>> see some convincing application example.
>
> But you can change signatures to add annotations?

Such annotation would only prevent from compiling code which was 
already undefined by documentation. Changing return type (which 
wasn't Voldemort type before) may break any program that has 
lines akin to `char[] data = foo()` - perfectly legal working 
code.

>> This sounds totally against my understanding of scope. I want 
>> scope exactly to
>> prohibit such actions. However it is possible in slightly 
>> modified way - where
>> you don't directly insert pointer to AST but use public method 
>> of AST control
>> structure that checks if supplied scope pointer belongs to 
>> list of nodes it
>> owns  and casts away scope after that.
>
> Wrappers do that, too.
>
> I know that 'wrapper' sounds bad to you, but one of the goals 
> of D's UDT's is to make it easy to adapt the behavior of a type 
> by wrapping it in a struct, rather than build new behavior into 
> the language.

Problem is that our UDT are simply not that good enough yet. 
Wrappers are fine in general but I want to wrap for less common 
cases and support more common ones natively. I suppose this is 
your intention too but we disagree on what is actually the common 
case and what is the special case.