On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
>
> * "volatile" has been one of the most awkward parts of the C and C++
> specifications. If we're to learn of anything about it, it's we must
> stay away from it. It is extremely heavy for what it provides.
> ...
>
> ==============
>
> I think an approach based on functions peek/poke is a lot more promising.

I am not saying that we should add volatile as a type qualifier, but it should be noted that programs with volatile type qualifiers can be lowered to programs using peek/poke and possibly other API calls with limited effort. (it is especially limited since the effort could be mostly shared with 'shared', both in specification and implementation, as it is another type qualifier that (will) (presumably) influence(s) the behaviour of loads and stores.)

On 7/18/2014 11:06 AM, Timon Gehr wrote:
> On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
>>
>> * "volatile" has been one of the most awkward parts of the C and C++
>> specifications. If we're to learn of anything about it, it's we must
>> stay away from it. It is extremely heavy for what it provides.
>> ...
>>
>> ==============
>>
>> I think an approach based on functions peek/poke is a lot more promising.
>
> I am not saying that we should add volatile as a type qualifier, but it should
> be noted that programs with volatile type qualifiers can be lowered to programs
> using peek/poke and possibly other API calls with limited effort. (it is
> especially limited since the effort could be mostly shared with 'shared', both
> in specification and implementation, as it is another type qualifier that (will)
> (presumably) influence(s) the behaviour of loads and stores.)

That doesn't change the heavy effort in the semantic front end and language specification to support volatile.

Take the C++ Standard and grep for 'volatile' and 'cv-qualifier'.

On 7/18/2014 10:53 AM, Timon Gehr wrote:
> I've grepped the DMD source and currently 'shared' is a _bit flag_ set or not
> set on some uint member field of the 'Type' class. I assume this is also the
> main reason why adding new type qualifiers is a really unpleasant undertaking:
> this is a highly non-modular design.

I also recommend that you grep the C++ Standard for 'volatile'.

I counted 137 occurrences by page 300 of 1353 pages, at that point I gave up. And those occurrences were not clustered, they were sprinkled everywhere.

A C++ compiler is obliged to carefully account for each and every semantic issue in the Standard. Just writing test cases for all those mentions is a major undertaking.

On 07/18/2014 08:37 PM, Walter Bright wrote:
> On 7/18/2014 11:06 AM, Timon Gehr wrote:
>> On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
>>>
>>> * "volatile" has been one of the most awkward parts of the C and C++
>>> specifications. If we're to learn of anything about it, it's we must
>>> stay away from it. It is extremely heavy for what it provides.
>>> ...
>>>
>>> ==============
>>>
>>> I think an approach based on functions peek/poke is a lot more
>>> promising.
>>
>> I am not saying that we should add volatile as a type qualifier, but
>> it should
>> be noted that programs with volatile type qualifiers can be lowered to
>> programs
>> using peek/poke and possibly other API calls with limited effort. (it is
>> especially limited since the effort could be mostly shared with
>> 'shared', both
>> in specification and implementation, as it is another type qualifier
>> that (will)
>> (presumably) influence(s) the behaviour of loads and stores.)
>
> That doesn't change the heavy effort in the semantic front end

What does this mean in detail? Is it just about the unfortunate AST representation chosen or are there more sources of heavy effort in the front end?

> and language specification to support volatile.
> ...

The language specification would just state what the rules for lowering are. In any case, I think the other points that Andrei raised are convincing enough.

On 7/18/2014 4:58 PM, Timon Gehr wrote:
> On 07/18/2014 08:37 PM, Walter Bright wrote:
>> That doesn't change the heavy effort in the semantic front end
>
> What does this mean in detail? Is it just about the unfortunate AST
> representation chosen or are there more sources of heavy effort in the front end?

Again, take a look at the hundreds of references to volatile all through the C++ specification for some idea.

On 07/19/2014 02:07 AM, Walter Bright wrote:
> On 7/18/2014 4:58 PM, Timon Gehr wrote:
>> On 07/18/2014 08:37 PM, Walter Bright wrote:
>>> That doesn't change the heavy effort in the semantic front end
>>
>> What does this mean in detail? Is it just about the unfortunate AST
>> representation chosen or are there more sources of heavy effort in the
>> front end?
>
> Again, take a look at the hundreds of references to volatile all through
> the C++ specification for some idea.
>

I am not suggesting to do what C++ does.

On 7/18/2014 6:16 PM, Timon Gehr wrote:
> On 07/19/2014 02:07 AM, Walter Bright wrote:
>> On 7/18/2014 4:58 PM, Timon Gehr wrote:
>>> On 07/18/2014 08:37 PM, Walter Bright wrote:
>>>> That doesn't change the heavy effort in the semantic front end
>>>
>>> What does this mean in detail? Is it just about the unfortunate AST
>>> representation chosen or are there more sources of heavy effort in the
>>> front end?
>>
>> Again, take a look at the hundreds of references to volatile all through
>> the C++ specification for some idea.
>>
>
> I am not suggesting to do what C++ does.

That is what DIP62 suggests - the only difference being transitivity.