To help LDC/GDC

[Timon Gehr]

On 04/08/2013 05:07 PM, Jacob Carlborg wrote:
> On 2013-04-08 14:52, Iain Buclaw wrote:
>> On 8 April 2013 13:25, Jacob Carlborg <doob at me.com <mailto:doob at me.com>>
>> wrote:
>>
>>     On 2013-04-08 10:29, Iain Buclaw wrote:
>>
>>         This information could possibly be helpful.  Though given that
>>         most of
>>         (gdc) codegen is on par with g++, there's probably not much on
>>         the list
>>         that isn't already detected by the backend optimisation passes.
>>
>>
>>     Multiple calls to pure functions could be cached.
>>
>>     --
>>     /Jacob Carlborg
>>
>>
>> Not always, but in some circumstances, yes.
>>
>> ---
>> struct Foo
>> {
>>    int a = 0;
>>    pure int bar (immutable int x)
>>    {
>>      ++a;
>>      return x * 2;
>>    }
>> }
>>
>>
>> void main()
>> {
>>    Foo f;
>>    int i = f.bar(2) + f.bar(2);
>>
>>    assert (i == 8);
>>    assert (f.a == 2);
>> }
>
> I though that wasn't possible. What's the point of pure if that's possible?
>

Foo.bar can be used in a strongly pure computation. It is superficially 
similar to how state transformers allow mutable state in Haskell.

If you want more guarantees, you could mark a member function const, 
inout or immutable pure.

DIP30 removes some optimization potential for at least const pure.

Furthermore, the exact meaning of inout will have to be determined. 
Unfortunately it is both useful to have a specifier that prevents 
mutation but allows to return a mutable part of the function input and 
to have a specifier that allows mutation in case the function input is 
in fact mutable.

Unfortunately, DMD does not implement type checking for delegates in a 
meaningful way. The specifiers const/immutable/pure should have 
consistent meanings for member functions and functions nested inside 
functions.

(http://d.puremagic.com/issues/show_bug.cgi?id=9148)