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