On Mon, Oct 15, 2018 at 7:15 PM Isaac S. via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > 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.
If you can give a single 'use', I'm all ears ;) > It's also easy to acknowledge that implicit conversion to shared > has its uses. I actually know of many real uses for this case. > 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. That might be fine. Like I said in OP, the first point that I think needs to be agreed on, is that shared can not read or write members. I think that's a pre-requisite for any interesting development.
