On 02.07.2017 01:08, Andrei Alexandrescu wrote:
Thanks! Well I do want to have a hierarchy with all possible qualifier
combinations for utmost clarity. Only the combinations listed are valid,
e.g. there's no "immutable inout" or whatever.
...
immutable(inout(T)) is valid syntax, but this type is equal to immutable(T).
Vaguely related question: should "const" convert implicitly to "const
shared"? The intuition is that the latter offers even less guarantees
than the former so it's the more general type. See
http://erdani.com/conversions3.svg.
That would be nice because we have "const shared" as the unique root of
the qualifier hierarchy.
This means that there can be aliasing between an unqualified reference
and a const shared reference. Therefore, you can have code that mutates
unshared data while another thread is reading it.
What should the semantics of this be?
The only potential issue is that it could restrict code operating on
unshared data because it needs to play nice in some way to allow
consistent data to be read by another thread.
