shared - i need it to be useful

[Isaac S.]

On Wednesday, 17 October 2018 at 03:50:44 UTC, Manu wrote:
> On Tue, Oct 16, 2018 at 8:20 PM Isaac S. via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>> *snip*
>>
>> 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.

I'm not objecting to the behavior (I actually really want it in 
the language as it allows for some really useful designs) but 
more-so saying it would be nice if it could be enabled or 
disabled. If its enabled-by-default, the @disable attribute could 
be used somehow (maybe "@disable alias this shared;").

Even without the ability to enable/disable shared implicit 
conversion it won't break my code, it'll just allow a potential 
bug. Since it does allow for extremely useful designs, I'll 
support this change (*even if it can't be enabled/disabled*).