pure or not pure?

[Janice Caron]

On 09/04/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> So how is new char[] a pure function?

new is special.

>  And why can't I 'wrap' new?  For
>  instance, if I have a function:
>
>  int[] createIncreasingSequence(int s, int e, int step){...}
>
>  which creates an array of ints that start at s and end at e, increasing by
>  step each time, why can't I make that pure?

I reckon you can, but you got the return type wrong.

    invariant(int)[] createIncreasingSequence(int s, int e, int step){...}
    {
        auto array = new int[(e-s)/step];
        foreach(ref a;array)
        {
            a = e;
            e += step;
        }
        return assumeUnique!(array);
    }


> i.e. I want to specify my own
>  way to initialize an array.  If I do that in 10 different pure functions,
>  you're saying I have to re-implement that code in each one?

To be honest, I don't understand the question.

The rule is : same input => same output

What happens in the middle, so long as it is side-effect free, doesn't matter.


> Surely there is some possible need for having run-time initialized invariant
>  variables...

You can do that. Walter confirmed that in response to a previous example I gave.

   import std.date;

   void main()
   {
       invariant s = toString(getUTCtime());

       pure string f()
       {
           return s;
       }

       writefln(s);
   }

Walter says f is pure. Ironically, the program will give a different
output each time it's run, but aparently purity only has to be global,
not universal.



>  > I think this is a /necessary/ restriction, because otherwise the
>  > following could not be typechecked:
>  >
>  >    class C
>  >    {
>  >        invariant int * p;
>  >
>  >        this(int * q)
>  >        {
>  >            p = q; // Big no no!
>  >        }
>  >    }
>
>
> Why would that compile?

Thankfully, it doesn't. But you were suggesting it should be possible
to initialize member variables which were declared invariant inside a
constructor, so I was demonstrating why this would not be a good idea.


>  If it did, then so would this:
>
>  this(int *q) invariant
>  {
>     p = q;
>  }

Not so. Invariant constructors have different typechecking rules.

Member variable p initially has type __raw(int *), which means it can
only be assigned with an invariant(int *), not with an int *.



>  I think invariant members that are run-time initialized can be done, as
>  during the constructor, nothing has access to the 'this' pointer.

"this" is certainly available during a constructor.


>  This was misleading on my part.  I should have asked instead of these two
>  questions, if substr is allowed to be pure,

which is a big "if", and I'm still hedging my bets on the answer being
no. But let's hypothetically assume it's yes for sake of argument.


> can it be called from a non-pure
> function?

There is nothing to stop you calling a pure function from a non-pure
function. So that would be a yes.


> In the context of being called from a pure function, src is
> unique, because pure has to have unique data.

No it doesn't. It has to have invariant data, not unique data. The
whole point about invariant data is it's OK to share it.