On Monday, 8 April 2013 at 12:41:23 UTC, Manu wrote:
> Not if it can still make external assignments though. pure in D is
> basically a lie! :,(

A lie? It's merely a different definition, and the stronger variant can easily – particularly be a compiler – be recovered by checking the argument types.

But yes, 'pure' should probably be the default in D.

David

On Monday, 8 April 2013 at 12:37:48 UTC, Manu wrote:
> On 8 April 2013 21:46, Iain Buclaw <ibuclaw@ubuntu.com> 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! >_<
>
> 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...

Iain, are you sure about that? (No offense, but you have been wrong about what GCC can/can't do in the past. :P) Could you maybe elaborate a bit and present a counterexample? It might also be a question of how the »as-if« rule is really defined for pure function calls.

In any case, if the source is available, the LLVM optimizer is usually very good at figuring out »pure for reals« (inferring the LLVM 'readnone' attribute). Obviously, this doesn't help you when you are doing separate compilation, though.

David

On Monday, 8 April 2013 at 13:32:36 UTC, David Nadlinger wrote:
> On Monday, 8 April 2013 at 12:37:48 UTC, Manu wrote:
>> On 8 April 2013 21:46, Iain Buclaw <ibuclaw@ubuntu.com> 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. […]
> Iain, are you sure about that?

(you also need nothrow, of course)

David

On 2013-04-08, 13:46, Iain Buclaw 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.

What?!?

Please give an example of this. What sort of internal state are we
talking about here?

-- 
Simen

On 04/08/2013 12:59 PM, Manu wrote:
> ...
>
> Does GDC have access to a GDC-specific __restrict attribute to tag stuff
> manually? I'm struggling to think where it can be automated...

As far as I can see, restrict can easily be applied to immutable data.

On Monday, 8 April 2013 at 13:13:22 UTC, Dicebot wrote:
> Casting away D const is undefined behavior. It is still not for single-threaded C++11 code AFAIK. That may make an important difference for optimization opportunities.

Minor correction, it is undefined to modify a const reference.

On 2013-04-08 14:41, Manu wrote:

> Not if it can still make external assignments though. pure in D is
> basically a lie! :,(

I'm taking about strong pure, whatever the difference is. I thought the the definition of "pure" was that it cannot touch global/external scope.

-- 
/Jacob Carlborg

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?

-- 
/Jacob Carlborg

On Monday, 8 April 2013 at 15:07:31 UTC, Jacob Carlborg wrote:
> I though that wasn't possible. What's the point of pure if that's possible?

Looks like one of problems that exist because "weakly pure" and "strongly pure" use the same keyword.

On 8 April 2013 14:40, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> On 2013-04-08, 13:46, Iain Buclaw 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.
>>
>
> What?!?
>
> Please give an example of this. What sort of internal state are we talking about here?


It might be weakly pure. ;)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';