bearophile Wrote:
> Probably there are ways to solve the situation, using unique or something > else, but I think that way leads to C++-style madness (see the ridiculously > complex lambdas of the last C++, they look like a joke to me. Those designers > have missed the point that the essential purpose of a lambda as used in > mostly imperative languages is to simplify code and the like, so having one > hundred optional features is bad). Keeping pure functions simple is the key > to allow their optimizations. Such complexity is necessary when you are trying to encapsulate functional benefits with imperative style. I happen to think we need unique for const/multithreading anyways, why not extend that to help pure functions be modularized? > > To solve your problem you can change your function fill() to restore its > purity (code untested): Yes, I thought of that solution. I intentionally did not write the code that way to illustrate the point I was trying to make. I'm expecting the reader to envision larger examples where it's not as convenient to change the modularization point, especially with previously existing functions that are hard to rewrite. Consider that you can't sort an array you create in a pure function without rewriting sort as a pure function! > Or you can just accept to not mark fill(), f() and g() as pure. fill cannot be pure, because it is only contextually pure (pure when called from a pure function). I'm not saying there is an easy solution, but the problems are not completely solved by the current methodology. If they can be solved, I think D will be in a class of it's own. -Steve
