On Sun, 10 Jun 2012 10:22:50 -0400, Artur Skawina <art.08...@gmail.com>
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.
Yes, this is correct.
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)
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.
-Steve
