http://d.puremagic.com/issues/show_bug.cgi?id=9674
--- Comment #9 from [email protected] 2013-03-10 01:55:54 PST --- (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #4 and #5) > > > > > > > The code depends on front of the source range being consistent across > > > > calls. > > > > > > front() is not tagged with "pure", ... > > > > How would that help? > > Pure _does_ make it consistent across calls. That's how it helps. :) Actually it does not. :) struct R{ int x; @property int front()pure{ return x++; } } I guess you want const pure. (but there are still type system holes.) > And arguably a range's front property - in theory - fits that shoe. As the > user > of a range I'd typically expect front to be a dumb, pure property. > > In this case it is incorrect to call map with a mapping function that accesses > global state for example. One issue is that recalculation may be expensive, or it might be cheap, or even removed by CSE. > Or front has to cache the last result, so it doesn't > need to ever be recalculated. But then practically every "front" property > should be cached and it starts to look like a design flaw. Agreed, it is not too clear what to do about this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
