valid uses of shared

[Artur Skawina]

On 06/11/12 12:35, Steven Schveighoffer wrote:
> On Sun, 10 Jun 2012 10:22:50 -0400, Artur Skawina <art.08.09 at gmail.com> wrote:
>> 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)

Yeah, and it makes using 'auto' less convenient - because then you have to cast
away const.

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

*The programmer* can then treat shared data just like unshared. Because every
load and every store will "magically" work. I'm afraid that after more than
two or three people touch the code, the chances of it being correct would be
less than 50%...
The fact that you can not (or shouldn't be able to) mix shared and unshared
freely is one of the main advantages of shared-annotation.

artur