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 <[email protected] <mailto:[email protected]>>
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)
