Proposal: Relax rules for 'pure'

[Tomek Sowiński]

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