`shared`...

Manu turkeyman at gmail.com
Mon Oct 1 02:29:40 UTC 2018


struct Bob
{
  void setThing() shared;
}

As I understand, `shared` attribution intends to guarantee that I dun
synchronisation internally.
This method is declared shared, so if I have shared instances, I can
call it... because it must handle thread-safety internally.

void f(ref shared Bob a, ref Bob b)
{
  a.setThing(); // I have a shared object, can call shared method

  b.setThing(); // ERROR
}

This is the bit of the design that doesn't make sense to me...
The method is shared, which suggests that it must handle
thread-safety. My instance `b` is NOT shared, that is, it is
thread-local.
So, I know that there's not a bunch of threads banging on this
object... but the shared method should still work! A method that
handles thread-safety doesn't suddenly not work when it's only
accessed from a single thread.

I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const... because
surely that's safe?

I'm not sure what the intended use here is... for every method I write
`shared`, I also need a non-shared shim that casts `&this` to shared,
and calls through... and that's just pointless and noisy busy-work.

The only reason I should have to overload for mutable and shared is
when I want to implement a non-thread-safe overload for performance
when interacting with non-shared instances.


More information about the Digitalmars-d mailing list