pure-ifying my code

[Philippe Sigaud]

On Sun, Nov 17, 2013 at 11:17 AM, Jonathan M Davis <jmdavisProg at gmx.com> 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.