http://d.puremagic.com/issues/show_bug.cgi?id=6169


bearophile_h...@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_h...@eml.cc


--- Comment #1 from bearophile_h...@eml.cc 2011-06-16 18:42:49 PDT ---
I think you have just made D a bit more complex :-)

In D compile time and run time are fully separated (and computing an enum
inside a CTFE function spans a fully separated and fully enclosed
sub-computation), so there is no way compile-time constants can break the
purity of a pure function. So this looks OK regarding run-time purity.

Currently in D in a function the path of compile-time execution has to be pure,
even if the whole function is not pure, so you are right saying this program
has to compile:


int x = 10;
int foo(bool b) {
    if (b)
        x++;
    return 0;
}
pure void main() {
    enum y = foo(false);
}


If in future D compilers CTFE will be allowed to modify global variables too,
then I think your idea is in troubles. Otherwise at first sight it seems OK,
but more thinking is required because future D compilers are allowed to perform
pure-related optimizations on pure functions even in CTFE. Is nonpurity able to
cause troubles to pure functions at compile-time?

In this program spam is pure, and it calls bar, that's not pure, to compute z.
But this program doesn't cause troubles even if a smart D compiler applies pure
optimization of spam()+spam() replacing it with spam()*2 because z is computed
only once, because bar() is called in a sub-computation that's fully sealed:


pure nothrow int foo() {
    int x = 1;
    nothrow int bar(int y) { // nonpure
        x++;
        return x + y;
    }

    pure nothrow int spam() {
        enum z = bar(1); // calls a nonpure
        return z;
    }
    return spam() + spam();
}

enum r = foo();
void main() {}


So if I am right, then this proposal is safe :-)

One problem left is that this proposal introduces another special case in D,
because the rules of purity have to say a pure function is allowed to call an
impure one at compile-time. Is it worth it? I think it's acceptable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to