shared - i need it to be useful

[Isaac S.]

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.