Semantics of shared

[Robert Jacques]

On Thu, 14 May 2009 13:12:46 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Robert Jacques wrote:
>> On Thu, 14 May 2009 02:13:37 -0400, Walter Bright  
>> <newshound1 at digitalmars.com> wrote:
>>
>>> Robert Jacques wrote:
>>>> I agree for POD, but what classes where the synchronization is  
>>>> encapsulated behind a virtual function call?
>>>
>>> synchronization can make a shared reference "tail shared".
>>  I agree, but that doesn't seem answer my question. Put another way, if  
>> I have an interface I which is implemented by both a thread local class  
>> L and a shared class S, then does some function F need to know about  
>> whether the implementor of I is S or L?
>
> Since a reference to thread local cannot be implicitly cast to shared,  
> then this scenario cannot happen - i.e. a shared function is not  
> covariant with an unshared one.
>> P.S. There will obviously be some interfaces S can't implement, but  
>> that a separate issue.
>>
>>>> Also, does this mean 'scope' as a type is going away?
>>>
>>> Scope never was a type, it's a storage class.
>>  Sorry for the confusion of terminology. However, you talk blog about  
>> using the 'scope' keyword to support escape analysis, ettc. i.e.  
>> 'scope' would become the 'const' of the shared-thread local-stack  
>> storage type system. Is this still the plan?
>
> I'm not sure what you mean by that.

I'm asking about the use of scope you blogged about:

http://dobbscodetalk.com/index.php?option=com_myblog&show=Escape-Analysis.html&Itemid=29

[...]

For D, we are looking at a design that creates a parameter storage class  
called scope:

T foo(scope int* p);

The presence of scope means that the function will not allow the  
parameter, or anything reachable through that parameter, to escape from  
the scope of the function. The scope storage class can be applied to the  
parameters or the 'this' reference (for member functions). Initially, this  
will be a promise by the implementor of foo(), but it should be entirely  
possible for the compiler to perform escape analysis using data flow  
analysis techniques on the implementation of foo() to ensure it. The  
caller of the function will know that a reference to a local variable can  
be safely passed as a scope parameter. A million line program can be  
automatically verified as being free of escaping reference bugs.