Bug 5750 – Allow pure functions to have lazy arguments

Any function marked as pure, which has a lazy parameter, should be considered to be weakly pure. Since a lazy parameter is a delegate, there are no limits on what it can potentially do, so the purity of the function will depend entirely on the purity of the lazy parameter. Secondly, when using a lazy parameter, it should be assumed to be adequately pure, since it was checked when it was constructed. PATCH: mtype.c, line 5042, void TypeFunction::purityLevel() size_t dim = Parameter::dim(tf->parameters); for (size_t i = 0; i < dim; i++) { Parameter *fparam = Parameter::getNth(tf->parameters, i); if (fparam->storageClass & STClazy) { - /* We could possibly allow this by doing further analysis on the - * lazy parameter to see if it's pure. - */ - error(0, "cannot have lazy parameters to a pure function"); + tf->purity = PUREweak; + break; } if (fparam->storageClass & STCout) expression.c, line 7155, CallExp::semantic() ---- if (sc->func && sc->func->isPure() && !tf->purity) { + if (e1->op == TOKvar && ((VarExp *)e1)->var->storage_class & STClazy) + { // lazy paramaters can be called without violating purity + // since they are checked explicitly + } + else error("pure function '%s' cannot call impure delegate '%s'", sc->func->toChars(), e1->toChars()); } if (sc->func && sc->func->isSafe() && tf->trust <= TRUSTsystem) { error("safe function '%s' cannot call system delegate '%s'", sc->func->toChars(), e1->toChars()); }

I definitely like this idea, but I am a bit worried that it will be somewhat buggy if integrated at present. I believe that there are at least a couple of bugs (such as bug# 3833 ) related delegates not dealing with attributes such as const and pure properly, and you can end up with attributes being ignored when they shouldn't be. That doesn't necessarily mean that this shouldn't be integrated right now, but it _does_ mean that the result could be buggy. I'm sure that Don has a far better understanding of all of that sort of compiler stuff than I do (and perhaps he's taken all of what I've said into account already), but I thought that I should point out that stuff like const and pure don't really seem to work properly with delegates, so this enhancement - while definitely desirable - may not work very well at the moment.

(In reply to comment #1) > I definitely like this idea, but I am a bit worried that it will be somewhat > buggy if integrated at present. I believe that there are at least a couple of > bugs (such as bug# 3833 ) related delegates not dealing with attributes such as > const and pure properly, and you can end up with attributes being ignored when > they shouldn't be. That doesn't necessarily mean that this shouldn't be > integrated right now, but it _does_ mean that the result could be buggy. Bug 3833 is totally unrelated to this. I have looked at all bugs which use the word "lazy" and none influence this. I've also looked at all open bugs which use the word "delegate" and also failed to find anything which influence this one. Bug 1818 is more related, but still isn't a problem. The main reason that none of those existing bugs cause problems is that enhancement bug 809 has NOT been accepted and "fixed". This means that although 'lazy' is internally implemented using delegates, there are very few places in the compiler where that fact is exposed. It stays as a lazy parameter almost all of the time, which isolates it from the other issues. Also worth noting: the patch fixes bug 5475, and would make fixing bug 5476 trivial.

(In reply to comment #2) Thank you for this bug report, Don, I was thinking about opening it. > Also worth noting: the patch fixes bug 5475, Do you mean bug 5745? Also, this helps bug 5746 too.

Where does the situation with this bug currently stand? Would it be at all safe at this point to put this patch (or a fixed up version of it if it's too old) into dmd and finally make functions which take lazy parameters able to be pure? This would be a huge gain for enforce in particular.

DMD pull #227. https://github.com/D-Programming-Language/dmd/pull/227