Robert Jacques Wrote:

> On Thu, 14 May 2009 02:13:37 -0400, Walter Bright <newshound1@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.
> > 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?

On Thu, 14 May 2009 08:51:37 -0400, Jason House <jason.james.house@gmail.com> wrote:

> Robert Jacques Wrote:
>
>> On Thu, 14 May 2009 02:13:37 -0400, Walter Bright
>> <newshound1@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?
>