Why is immutable not possible as a result of a reduce expression?

[monarch_dodra]

On Saturday, 5 January 2013 at 20:09:24 UTC, Simen Kjaeraas wrote:
>
> The reason is that ranges may not be immutable or const.
>
> Ranges need to be mutated (popFront) to be iterable, and your 
> filtered
> range cannot be mutated, by virtue of being immutable. I'm 
> surprised that
> seq and filtered work, but I guess there may be specializations 
> that
> circumvent the problem.

No, they just make the erroneous assumption that copying strips 
immutablity. There are cases where this is true, but not always. 
The *only* time when this is true is with arrays, where 
"immutable(T[])" can be copied to a "immutable(T)[]". Even then, 
the compiler strips to top immutable of the type implicitly, so 
no extra code should be rolled out for it anyways...

IMO, the only sensible behavior when calling "auto 
filter!(immutable R)(r)" would be to return an "immutable 
Filter!R" initialized with r...
...but you'd have to do it with the actual "immutable 
constructor". Simply creating a Filter!R and then castng it to 
immutable would also be wrong.

Ditto for all other range types. I'll try and review them.