valid uses of shared

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 11 03:35:31 PDT 2012


On Sun, 10 Jun 2012 10:22:50 -0400, Artur Skawina <art.08.09 at gmail.com>  
wrote:

> On 06/10/12 10:51, Mehrdad wrote:
>> On Friday, 8 June 2012 at 04:03:08 UTC, Steven Schveighoffer wrote:
>>> I agree that the type should be shared(int), but the type should not  
>>> transfer to function calls or auto, it should be sticky to the  
>>> particular variable.
>>
>>
>> I think that's a pretty fundamental problem:
>>
>> Shared is a type constructor, but you just mentioned that it has to be  
>> a property of the _variable_, i.e. a storage class.
>
> Actually, no. What Steven is saying is that a _copy_ of the variable  
> (the result
> of an expression, in general) does not need to retain the same  
> qualifiers, such
> as 'shared' or 'const'. It means that the result does have a different  
> type, but
> that's ok, as it's a different entity.

Yes, this is correct.

> This is obviously fine:
>
>    const int[8] a; auto p = &a[0]; // typeof(p)==const(int)*
>
> as we just created the pointer, there's no need for it to be const, it  
> just needs
> to point to 'const'.
>
> Now consider:
>
>    const int*[8] a; auto p = a[0]; // typeof(p)==const(int)*
>
> Here we *also* create a new pointer, so it does not need to be const  
> either. The
> only difference is in how the *value* of this new pointer is obtained.  
> In the
> 'const' case the data (pointer value) can just be read from the memory  
> location
> and the operation is always perfectly safe.

The worst is this one:

const int[8] a;  auto e = a[0]; // typeof(p) == const(int) (in current  
compiler)

> The reason I don't want this to happen when dealing with 'shared' is not  
> that it's
> wrong, it isn't. It's because it would make writing  
> unsafe/confusing/buggy code
> too easy, as you then can completely ignore the 'shared' aspect.

I wholly disagree.  In fact, keeping the full qualifier intact *enforces*  
incorrect code, because you are forcing shared semantics on literally  
unshared data.

Never would this start ignoring shared on data that is truly shared.  This  
is why I don't really get your argument.

If you could perhaps explain with an example, it might be helpful.

-Steve


More information about the Digitalmars-d mailing list