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@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*).
