On Sun, Nov 17, 2013 at 11:17 AM, Jonathan M Davis <[email protected]> wrote:
>> DMD tells me `foo` cannot use the impure `joiner`, due to >> `joiner`'s internal struct (Result) not having pure methods >> (`empty`/`front`/`popFront`). >> >> Now, it seems obvious why these range methods are not pure >> (`popFront`, at least). > > All of them should be able to be pure, as none of them access global or static > variables. But `popFront()` changes an internal state with visible, external effects: it changes `front` return value and in the end, it will affect `empty` return value. So no, I don't consider `popFront` to be pure. But my problem is: I don't use them! I just create a struct value that happens to have them as methods. But that should not affect my own `foo` purity, right? >> But I don't use them in my function! I >> just return a lazy range to iterate on other ranges. My own >> function do not mutate anything, it just creates an object. A >> mutable value admittedly, but not one with global state. >> >> I know Phobos is not using `pure` as much as it could right now, >> but I really don't see why it's causing trouble right there. > > Likely because it's calling an impure constructor. The compiler does not > currently properly infer purity for Voldemort types. > > https://d.puremagic.com/issues/show_bug.cgi?id=10329 > > Really, the compiler's attribute inferrence is pretty pathetic at this point. > It only manages to infer attributes in the most basic of cases, and that's the > number one reason that so little of Phobos works with pure right now. Ah right, a Voldemort type, I did not know they could affect purity determination. I find they regularly cause problems. Whenever I create one, I then have to extract it from its enclosing father. I'll create my own simplified version of joiner for this problem. My current code use an eager computation and I don't want that.
