On Monday, 8 April 2013 at 15:07:31 UTC, Jacob Carlborg wrote:
> On 2013-04-08 14:52, Iain Buclaw wrote:
>> On 8 April 2013 13:25, Jacob Carlborg <doob@me.com <mailto:doob@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?

You have to think that this is an hidden parameter. The function touch that parameter, no global state.

On 4/8/2013 5:39 AM, Manu wrote:
> But D makes no further guarantee. I don't see how const in D is any different
> than const in C++ in that sense? That's basically the concept of const, it's not
> a useful concept for optimisation, only immutable is.

In C++, it is legal to cast away const and mutate it. That is undefined behavior in D.

A D compiler can assume, for example, that a const reference passed to a pure function will not mutate that reference, nor anything transitively referred to by that reference. No such assumption can be made like that in C++.

On 4/8/2013 5:37 AM, Manu wrote:
>     Only builtins are pure in the sense of 'C'.  Even functions considered
>     PUREstrong by the frontend may update an internal state, so the rules just
>     don't apply.  Except for maybe global functions...   In any case, the only
>     benefit you can reap from 'D pure' functions are that they are more likely
>     to be const-folded / inlined.
>
> Oh my god... ..... this is the most upsetting thing I've heard all day! :(
> No really, I have been SOOOO excited for so long about this optimisation
> potential in D!
> There's gotta be something that can be done! >_<

I believe Iain is incorrect. Pure functions cannot squirrel away any persistent state.

On 4/8/2013 11:20 AM, Johannes Pfau wrote:
> (Though admittedly I'm not sure if there's any optimization potential
> with nothrow)

There is. The setting up of the exception handling frames can be omitted, and eh frames prevent enregistering of many variables.

On 2013-04-09 05:30, Walter Bright wrote:

> In C++, it is legal to cast away const and mutate it. That is undefined
> behavior in D.

Didn't they change how const behaves in C++11, I'm thinking of this:

http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank

-- 
/Jacob Carlborg

On 9 April 2013 01:07, Jacob Carlborg <doob@me.com> wrote:

> On 2013-04-08 14:52, Iain Buclaw wrote:
>
>> On 8 April 2013 13:25, Jacob Carlborg <doob@me.com <mailto:doob@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?


Precisely >_<

On 9 April 2013 01:40, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 8 April 2013 13:37, Manu <turkeyman@gmail.com> wrote:
>
>> Oh my god... ..... this is the most upsetting thing I've heard all day! :(
>> No really, I have been SOOOO excited for so long about this optimisation
>> potential in D!
>> There's gotta be something that can be done! >_<
>>
>> Does the front end know if the function actually DOES assign to any
>> state? The compiler could easily work that out, and in the event it doesn't
>> actually perform any such assignment, it could be marked pure for reals...
>>
>>
> Haven't looked, but it appears to have a general idea of this.  D 'weak pure' and 'const pure' may update an internal state (had the latter bite me hard once).  The only case where 'strong pure' might do this is by throwing an exception or an assert being thrown - this changes program state so can't be marked pure.
>
> So having identified this, we can safely say that functions could only be
> 'C pure' in the following case:
> - Compiled function is 'strong pure'
> - Compiled function is 'nothrow'
> - We are compiling in release mode.
>
> Only then we (the frontend) can safely say that 'this function has *absolutely* no side effects, so can be marked as pure'.   Pure is never inferred.
>

How does one specify that in their code? Is 'strong pure' a keyword?

On 9 April 2013 13:30, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/8/2013 5:39 AM, Manu wrote:
>
>> But D makes no further guarantee. I don't see how const in D is any
>> different
>> than const in C++ in that sense? That's basically the concept of const,
>> it's not
>> a useful concept for optimisation, only immutable is.
>>
>
> In C++, it is legal to cast away const and mutate it. That is undefined behavior in D.
>
> A D compiler can assume, for example, that a const reference passed to a pure function will not mutate that reference, nor anything transitively referred to by that reference. No such assumption can be made like that in C++.
>

But that's meaningless though, because there's always the possibility that
something somewhere else may have a non-const reference to that thing.
Can you suggest a case where const could EVER be used in any sort of
optimisation?
I don't think const can possibly offer anything to the optimiser in any
language, only type safety... I'd love to be wrong.

On Tuesday, 9 April 2013 at 07:11:02 UTC, Jacob Carlborg wrote:
> On 2013-04-09 05:30, Walter Bright wrote:
>
>> In C++, it is legal to cast away const and mutate it. That is undefined
>> behavior in D.
>
> Didn't they change how const behaves in C++11, I'm thinking of this:
>
> http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank

Yes, but it is changed only for multi-threaded code (because the very concept of concurrency is defined first in C++11). Single-thread semantics remain the same.

On Tuesday, 9 April 2013 at 07:52:20 UTC, Manu wrote:
> But that's meaningless though, because there's always the possibility that
> something somewhere else may have a non-const reference to that thing.
> Can you suggest a case where const could EVER be used in any sort of
> optimisation?
> I don't think const can possibly offer anything to the optimiser in any
> language, only type safety... I'd love to be wrong.

Don't forget, D variables are thread-local by default. If you get a const variable that is not shared or __gshared, compiler can safely assume that it will never change in this scope.