Michel Fortin napisał: >> It's because popFront() can't be made pure. It could be if there was >> @tail immutable in the >> language -- pure functions would mark their arguments with @tail >> immutable instead of >> immutable. That allows popFront() to advance the range. > > I know popFront() can't be made pure by the current rules. The proposal > that started this thread is to relax 'pure' so that popFront() can be > made pure. I was simply pointing a use case for that. > > And to tell the truth, I have no idea where a tail-immutable qualifier > would be helpful in this situation... could you elaborate?
I wrote that before I read Don's re-explanation that pure should just mean no globals (weak- pure) and it's to be able to call weak-pure functions from const-pure and immutable-pure functions that do impose restrictions on their parameters and offer guarantees about parallelizing, enable optimizations, etc. And that's cool. So in the "three levels of purity" nomenclature, tail(const|immutable) would popularize the stronger two. E.g. popFront() could be immutably pure if the range in on an immutable collection and const-pure if it's on any collection. -- Tomek
