Semantics of shared

[Robert Jacques]

On Thu, 14 May 2009 08:51:37 -0400, Jason House  
<jason.james.house at gmail.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?
>
> Shared data needs fundamentally different handling than thread local  
> data. I expect "shared I" and "__thread I" to be handled differently.  
> You can't store an S where an L is expected... It can break code.
>
>> 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?
>
> Of course not. Scope storage class will remain.

The use of scope I'm talking about (see below) isn't even implemented yet,  
so how can it remain? It was Walter bogged a while ago about using the  
scope keyword to aid escape analysis, which would provide a common type  
for shared-local-stack allocation. I'm not referring to the use of 'scope'  
to stack allocate a class.

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