On Tuesday, 16 October 2018 at 00:36:12 UTC, Manu wrote:
*snip*
Yes, except maybe I didn't make it clear that I DO expect the
un-shared methods to be aware that a sibling shared method does
exist
(you wrote it!), and that it may manipulate some state, so *if*
the
un-shared method does interact with the same data that the
shared
method may manipulate (in many cases, it won't; it's likely
only a
small subset of an object's functionality that may have
thread-safe
access), then the un-shared method does need to acknowledge that
functional overlap.
So even though a method is un-shared, it still needs to be
aware that
it may have sibling methods that are shared. If they don't
access an
overlapping data-set, no special handling is required. If they
do
overlap, they may need to coordinate appropriately.
I understand your point but I think the current shared (no
implicit conversion) has its uses. It can be quite useful to have
one interface for when an object is shared and one for when it is
not (one with and without the synchronization cost). Sure,
something as trivial as a counter can be re-implemented in both
ways but more complex objects would easily result in extreme code
duplication.
It's also easy to acknowledge that implicit conversion to shared
has its uses.
Instead of forcing one way or another, how about we leave the
decision up to the programmer? Say something like "alias this
shared;" enables implicit conversion to shared.
