Something needs to happen with shared, and soon.

[Simen Kjaeraas]

On 2012-11-12, 15:11, Jacob Carlborg wrote:

> On 2012-11-12 12:55, Regan Heath wrote:
>> On Mon, 12 Nov 2012 02:30:17 -0000, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>> To make a shared type work in an algorithm, you have to:
>>>
>>> 1. ensure single threaded access by aquiring a mutex
>>> 2. cast away shared
>>> 3. operate on the data
>>> 4. cast back to shared
>>> 5. release the mutex
>>
>> So what we actually want, in order to make the above "nice" is a
>> "scoped" struct wrapping the mutex and shared object which does all the
>> "dirty" work for you.  I'm thinking..
>>
>> // (0)
>> with(ScopedLock(obj,lock))  // (1)
>> {
>>    obj.foo = 2;              // (2)
>> }                           // (3)
>> // (4)
>>
>> (0) obj is a "shared" reference, lock is a global mutex
>> (1) mutex is acquired here, shared is cast away
>> (2) 'obj' is not "shared" here so data access is allowed
>> (3) ScopedLock is "destroyed" and the mutex released
>> (4) obj is shared again
>>
>> I think most of the above can be done without any compiler support but
>> it would be "nice" if the compiler did something clever with 'obj' such
>> that it knew it wasn't 'shared' inside the the 'with' above.  If not, if
>> a full library solution is desired we could always have another
>> temporary "unshared" variable referencing obj.
>
> I'm just throwing it in here again, AST macros could probably solve this.

Until someone writes a proper DIP on them, macros can write entire software
packages, download Hitler, turn D into lisp, and bake bread. Can we please
stop with the 'macros could do that' until there's any sort of consensus as
to what macros *could* do?

-- 
Simen