Paper acknowledges positively D's approach to purity

[Dave]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:galdu2$pou$1 at digitalmars.com...
> bearophile wrote:
>> Andrei Alexandrescu:
>>> It's a great honor and validation to be acknowledged in a paper of
>>> such quality and to see D's approach to purity not only mentioned,
>>> but in praise terms nonetheless (section 9).
>>
>> It seems to contain some comments that are not a praise too:
>>
>>> While this approach avoids the need to eliminate mutable state and
>>> determinism from the global scope, there is a substantial cost in
>>> expressivity as it prevents pure functions from making any use of
>>> impure functions and methods. The result is essentially of a
>>> partition of the program into imperative and purely functional
>>> portions, whereas our approach allows pure functions to make full
>>> use of the rest of the program, limited only by the references they
>>> hold.<
>

"The result is essentially of a partition of the program into imperative and 
purely functional portions..."

Isn't that a bit strong, even in the context of that paper, since pure 
functions and their return values can be used anywhere in the imperative 
'portion' of a program?

Also, couldn't D2's ability to initialize invariants at runtime (for example 
in a class or struct ctor) for use in pure functions bridge most of that gap 
fairly reasonably in many cases? For example, in the article's Voting 
Machine, a class with invariant data members representing a de/serialized 
Ballot could be instantiated and the results kept invariant until after the 
data was verified with pure function(s)?

> Any paper will mention the disadvantages of related work in the pertinent 
> section. I'm not worried about that at all. Their system is more 
> expressive but also considerably more complex. That's not necessarily bad, 
> it's a different point in tradeoff space.
>

Given that invariants are vital to 'pure' programming in D, could the 
tradeoff be made less onerous for the programmer with a few relatively minor 
changes to the invariant initialization spec?

One thing off-hand that makes it tougher to use invariant reference types is 
the requirement to cast during initialization  (which is also inconsistent 
with value types):

class C
{
    invariant int sz;
    invariant int[] arr;
    this(size_t sz)
    {
        this.sz = sz;    // Value types don't require a cast to invariant 
(same with UDT's).

        //arr = new int[sz];
        arr = cast(invariant int[])new int[sz];    // Reference types do.

        //foreach(i, ref val; arr)
        foreach(i, ref val; cast(int[])arr)
        {
            val = i;
        }

        // Or
        for(size_t i = 0; i < sz; i++)
        {
            //arr[i] = i;
            cast(int)arr[i] = i;
        }
    }

    ~this()
    {
        delete arr;                             // OK in dtor.
    }
}

- Dave