Vision for the D language - stabilizing complexity?

[Steven Schveighoffer via Digitalmars-d]

On 7/12/16 12:01 PM, Andrei Alexandrescu wrote:
> On 07/12/2016 11:07 AM, Steven Schveighoffer wrote:
>> A related question: are we planning on making such access pure (or even
>> allowing compiler to infer purity)? If so, we may have issues...
>
> Was that the link you posted? What's a summary of the issues and what do
> you think would be a proper way to address them? Thanks! -- Andrei

No, the link I posted was a poor proposal by a (much?) younger me to do 
a similar thing to the affix allocator (but on the language level). 
Apparently, I didn't have enough cred back then :)

The issue I'm referring to is the compiler eliding calls.

For example, let's say you have a reference counted type:

RC(T)
{
    T *value
}

And T is immutable. So far so good.

Now, we do this:

RC(T)
{
    alias MyAllocator = ...; // some form of affixallocator
    void incRef() { MyAllocator.prefix(value)++; }
}

Seems innocuous enough. However, if the compiler interprets incRef to be 
pure, and notices that "hey, all the parameters to this function are 
immutable, and it returns void! I don't have to call this, win-win!"

Then we have a problem. I raised similar points when C free was made 
pure (but to no avail).

It's not necessarily an unfixable problem, but we may need some language 
help to guarantee these aren't elided.

-Steve