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.
