Why do "const inout" and "const inout shared" exist?

Shachar Shemesh via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 2 05:46:36 PDT 2017


On 02/07/17 15:31, Andrei Alexandrescu wrote:
> That supports the case for allowing the conversion.
> 
> const: "You have a view to data that this thread may or may not change."
> 
> const shared: "You have a view to data that any thread may or may not 
> change."
> 
> So the set of const is included in the set of const shared - texbook 
> inclusion polymorphism.
> 

It does, with two (or is that three?) caveats.

First, I have 0 (zero) experience with shared, so I don't know what 
barriers are used on access. If they're expensive, this combining of the 
type system might be a problem.

Second, there are optimizations that can take place over "const" that 
cannot over "shared const" even assuming aliasing (such as if the 
compiler knows no other pointer was changed between two accesses).

The last point is that assuming no pointer aliasing is a fairly common 
optimization to take in C and C++, simply because of the huge 
performance gains it provides. It is so huge that it is sometimes turned 
on by default despite the fact it changes language semantics. It would 
be a pity to block any potential to have it in D.

Just my humble opinion.

Shachar


More information about the Digitalmars-d mailing list