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.
