On 02.07.2017 14:31, Andrei Alexandrescu wrote:
On 07/02/2017 02:49 AM, Shachar Shemesh wrote:
On 02/07/17 02:08, Andrei Alexandrescu wrote:
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.
I don't see how it can. They provide different guarantees. If
anything, it should be the other way around.
If you hold a pointer to const, you know the data will not change
during the function's execution. No such guarantees for const shared.
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.
This is not the whole story. The best way to think about 'shared' is
that it enables guarantees about data that does /not/ have the
qualifier. So we need to look at what this change does to the meaning of
data being unqualified:
It changes from:
unqualified: This data can be read and written exclusively by the
current thread.
to
unqualified: This data can be read and written by this thread and read
by any other thread.
This disallows some program transformations that were allowed before
unless reading from a const shared reference while a mutable thread is
writing to it has an undefined result, in which case the change just
removes /all/ guarantees from const shared just in order to place it at
the top of the hierarchy. At this point you can just use void*.
