[dmd-internals] Regarding deprecation of volatile statements

[Artur Skawina]

On 08/01/12 03:59, Alex Rønne Petersen wrote:
> implement a feature that is rather essential for a systems language,
> and especially in the year 2012? I understand that there are
> difficulties in working out the exact semantics, but I'm sure we can
> get there, and I think we should, instead of just hack-fixing a

The first step to getting there would be discussing changes to the
/language/ in a more visible place... The only reason I had to subscribe
to lists such as this one or 'beta' is because of the dubious ideas
and suggestions that only appear here.

D's volatile statements were a mistake; since they are already
deprecated and obviously flawed, I never saw the need to actually
even mention this; i was just waiting until they are gone, so that
a sane 'volatile' can be introduced. Your suggestion has the same
problems; it does not help, but instead would make fixing the language
harder (by keeping the current broken incarnation of volatile around).

The issues w/ volatile statements are really obvious, eg

What does this do?

   C c; D d;
   //...
   volatile d.i = c.i++;
   //...

What about this?

   int e;
   volatile e = c.i;

Even introducing volatile /expresions/ wouldn't solve the problem,
it's just the wrong tool for the job. 'volatile' is a property of
the data (access), not of expressions/statements.

Now imagine if 'C.i' was marked with a 'volatile' attribute. Both
of the above examples would get sane semantics, which otherwise
can only be approximated using explicit temporary dummy variables.

'volatile' statements are just as broken as 'shared' statements
would be:

   shared { a = b; } // which access is the shared one? both?

Your arguments in the DIP againts a C-like attribute are equally
valid against the "rather nonsensical" volatile statements examples:

   int i;

   volatile
   {
      i = 1;
      i = 2;
   }

which, btw, are not entirely nonsensical, as you may want i's on-stack
(or -heap in case of closures) representation to be kept updated at all
times. Which isn't a common requirement, but there is no reason to disallow
this usage. It can obviously be expressed using compiler barriers too, but
having every access automatically treated specially is much better than 
having to always remember to mark it as 'volatile' everywhere or wrap it.
Think templates, etc.

artur