On Tue, Oct 16, 2018 at 8:20 PM Isaac S. via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Tuesday, 16 October 2018 at 06:21:22 UTC, Manu wrote: > > On Mon, Oct 15, 2018 at 8:55 PM Isaac S. via Digitalmars-d > > <digitalmars-d@puremagic.com> wrote: > >> > >> On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote: > >> >> I understand your point but I think the current shared (no > >> >> implicit conversion) has its uses. > >> >> *snip* > >> > > >> > If you can give a single 'use', I'm all ears ;) > >> > >> My usages are a custom ref counted template and list types > >> (which are built on top of the former). The ref counted > >> template will initialize naively when not shared but utilize > >> compare-and-set and thread yielding if needed when shared > >> (ensureInitialized can occur any time after declaration). The > >> list types (which are not shared-compatible *yet*) will > >> utilize a read-write mutex only when shared (no cost beyond a > >> little unused memory to non-shared objects). As such, casting > >> any of the non-shared versions of these types to shared would > >> be unsafe. > >> > >> (Technically the types can be safely casted to shared so long > >> as no non-shared reference to them exists and vice versa.) > > > > Can you link to code? It doesn't sound incompatible with my > > proposal. Mutexes are blunt instruments, and easy to model. My > > whole suggestion has virtually no effect on the mutex protected > > case, which is what most people seem to talk about. > > On Wednesday, 17 October 2018 at 00:26:58 UTC, Manu wrote: > > *snip* > > > > Overloading for shared and unshared is possible, and may be > > desirable in many cases. > > There are also many cases where the code duplication and > > tech-debt > > does not carry its weight. It should not be required, because > > it's not technically required. > > Overloading for shared and unshared is my reason for not allowing > implicit conversion on my types (I have no problems with implicit > conversion being optional or disableable). The unshared function > performs no synchronization of any kind while the shared function > always does. This means that having an unshared and shared > reference to the same object is unsafe.
Okay, so just to be clear, you're objecting to an immensely useful behaviour because you exploit the current design as an optimisation potential? That said, I'm still not taking anything away from you... you can still implement your class that way if you like, no change will affect that decision. You obviously have mechanisms in place to guarantee the thread-local-ness of your object (otherwise it wouldn't work), so, assuming you implement the unshared overload to be unsafe, then situation hasn't changed for you at all...? I don't think a robust middleware would make that trade-off, but an application can do that if it wishes. Trading implicit safety (enforcing it externally via application context) for perf is not unusual at all. > As to the larger part of preventing reading/writing of shared > objects, I agree with its purpose and have no problems with it. Right, the implicit cast thing is secondary to this fundamental part. I think it's worth first focusing on getting that rule right. shared = no read + no write .. I don't think that's objectionable.
