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.

Reply via email to