valid uses of shared

[Timon Gehr]

On 06/10/2012 04:22 PM, Artur Skawina 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.
>
> 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 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.
>
> artur

I can't follow the line of reasoning here.

>
> PS. That second const example does not describe current behavior - the compiler
> infers 'p' as const, which is wrong.

It is by design. However, it would usually be more convenient if it was 
as you describe.