valid uses of shared

[Artur Skawina]

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

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