Trying to get the most out of the current 'shared' system

[Sönke Ludwig]

Am 12.11.2012 13:33, schrieb Regan Heath:
> On Mon, 12 Nov 2012 11:41:00 -0000, Sönke Ludwig
> <sludwig at outerproduct.org> wrote:
> 
>> Am 11.11.2012 19:46, schrieb Alex Rønne Petersen:
>>> Something needs to be done about shared. I don't know what, but the
>>> current situation is -- and I'm really not exaggerating here --
>>> laughable. I think we either need to just make it perfectly clear that
>>> shared is for documentation purposes and nothing else, or, figure out an
>>> alternative system to shared, because I don't see shared actually being
>>> useful for real world work no matter what we do with it.
>>>
>>
>> After reading Walter's comment, it suddenly seemed obvious that we are
>> currently using 'shared' the wrong way. Shared is just not meant to be
>> used on objects at all (or only in some special cases like
>> synchronization primitives). I just experimented a bit with a statically
>> checked library based solution and a nice way to use shared is to only
>> use it for disabling access to non-shared members while its monitor is
>> not locked. A ScopedLock proxy and a lock() function can be used for
>> this:
> 
> I had exactly the same idea:
> http://forum.dlang.org/thread/k7orpj$1tt5$1@digitalmars.com?page=2#post-op.wnnsrds954xghj:40puck.auriga.bhead.co.uk
> 
> 
> But, then I went right back the other way:
> http://forum.dlang.org/thread/k7orpj$1tt5$1@digitalmars.com?page=2#post-op.wnnt4iyz54xghj:40puck.auriga.bhead.co.uk
> 
> 
> I think we can definitely create a library solution like the one you
> propose below, and it should work quite well.  But, I reckon it would be
> even nicer if the compiler did just a little bit of the work for us, and
> we integrated with the built in synchronized statement. :)
> 
> R
> 

The only problem is that for this approach to be safe, any aliasing
outside of the object's reference tree that is not 'shared', must be
disallowed. To get the maximum use out of this, some kind of
'isolated'/'unique' qualifier is needed again.

So a built-in language solution - which would definitely be highly
desirable - that allows this would also either have to introduce a new
type qualifier, or recognize the corresponding library structure which
implements this. Since for various reasons both possibilities have a
questionable probability of being implemented, I decided to go and see
what can be done with the current state. By now I would be more than
happy to have _any_ decent solution that works and that can also be
recommend to others.