Helping with __mutable (which will be renamed to __metadata)

[Steven Schveighoffer]

On 4/15/19 8:49 AM, Timon Gehr wrote:
> On 15.04.19 14:32, Steven Schveighoffer wrote:
>> On 4/15/19 7:17 AM, Timon Gehr wrote:
>>> On 14.04.19 22:55, Suleyman wrote:
>>>> On Sunday, 14 April 2019 at 00:38:16 UTC, Timon Gehr wrote:
>>>>> which implies that there are wrong ways to use `__mutable` (hence 
>>>>> unsafe)
>>>>
>>>> can you elaborate?
>>>>
>>>
>>> struct S{
>>>      private __metadata x;
>>> }
>>>
>>> void foo(immutable ref S s)pure{
>>>      s.x += 1;
>>> }
>>>
>>> void main(){
>>>      immutable S s;
>>>      foo(s); // there is no reason for this call to happen
>>>      assert(s.x==1); // can't rely on this, it might also be 0
>>> }
>>>
>>> struct S{
>>>      private __mutable x;
>>> }
>>>
>>> int foo(immutable ref S s)pure{
>>>      s.x += 1;
>>>      return s.x;
>>> }
>>>
>>> void main(){
>>>      immutable S s;
>>>      int a=foo(s);
>>>      int b=foo(s); // could just reuse the previous result
>>>      assert(a!=b); // can't rely on this, might be the same
>>> }
>>
>> Note that this is exactly the use case of reference counting. Which is 
>> the main draw of having a mutable portion of an immutable. I would 
>> hazard to guess that if the above has to be the semantics, this is DOA.
>>
> No, this is clearly not the use case of reference counting. Where do you 
> see references that are being counted?
> Why should the fact that the data structure is reference counted block 
> optimizations such as eliding reference copies?

I mean when you add/remove reference for an immutable, it's passing an 
immutable to what needs to be a pure function, which then 
increments/decrements a __metadata field (just like your examples 
above). If one of those 2 gets elided, the reference count is hosed.

-Steve