I'm trying to annotate some code with pure and nothrow (mostly just to test it out and give feedback at this point), and I've noticed one very irritating thing.  If I use a struct as follows:

struct LameStruct {
    uint foo;
    uint bar;

    void doStuff() {
        foo++;
        bar++;
    }
}

void foo() {
    LameStruct lamestruct;
    s.doStuff();
}

foo() cannot be annotated as pure in this case because technically, it calls
doStuff(), which modifies lamestruct.  However, I think in this fairly simple
case, DMD could reasonably figure out that this function is still
referentially transparent and safe for multithreading, at least if LameStruct
is defined in the same module as foo().  Of course, no other function can have
access to lamestruct before foo() is called because it is created within
foo().  Furthermore, doStuff() only modifies value types that it owns, and the
return type is void.

Will pure eventually be expanded to deal with more cases where the referential transparency and inherent thread-safety of a function is obvious to humans, like these, or is this simply asking too much?

== Quote from dsimcha (dsimcha@yahoo.com)'s article
> I'm trying to annotate some code with pure and nothrow (mostly just to test it
> out and give feedback at this point), and I've noticed one very irritating
> thing.  If I use a struct as follows:
> struct LameStruct {
>     uint foo;
>     uint bar;
>     void doStuff() {
>         foo++;
>         bar++;
>     }
> }
> void foo() {
>     LameStruct lamestruct;
>     s.doStuff();
> }
> foo() cannot be annotated as pure in this case because technically, it calls
> doStuff(), which modifies lamestruct.  However, I think in this fairly simple
> case, DMD could reasonably figure out that this function is still
> referentially transparent and safe for multithreading, at least if LameStruct
> is defined in the same module as foo().  Of course, no other function can have
> access to lamestruct before foo() is called because it is created within
> foo().  Furthermore, doStuff() only modifies value types that it owns, and the
> return type is void.
> Will pure eventually be expanded to deal with more cases where the referential
> transparency and inherent thread-safety of a function is obvious to humans,
> like these, or is this simply asking too much?

Oh, and I just realize my silly mistake and I apologize.  Of course nobody writes referentially transparent functions that return void.  Please pretend foo() returns something that would be consistent with it being pure.

dsimcha wrote:
> Will pure eventually be expanded to deal with more cases where the referential
> transparency and inherent thread-safety of a function is obvious to humans,
> like these, or is this simply asking too much?

If it can be proven (and it can in your example) it can be pure.

Walter Bright wrote:
> dsimcha wrote:
>> Will pure eventually be expanded to deal with more cases where the
>> referential
>> transparency and inherent thread-safety of a function is obvious to
>> humans,
>> like these, or is this simply asking too much?
> 
> If it can be proven (and it can in your example) it can be pure.

I'm curious, how difficult is it to mechanically prove/disprove purity in the general case?

I thought this was going to be one of those things like escape analysis, where we'd have to settle for a subset of the provable cases for the sake of easy of implementation.

Chad J wrote:
> Walter Bright wrote:
>> dsimcha wrote:
>>> Will pure eventually be expanded to deal with more cases where the
>>> referential
>>> transparency and inherent thread-safety of a function is obvious to
>>> humans,
>>> like these, or is this simply asking too much?
>> If it can be proven (and it can in your example) it can be pure.
> 
> I'm curious, how difficult is it to mechanically prove/disprove purity
> in the general case?

I don't know.


> I thought this was going to be one of those things like escape analysis,
> where we'd have to settle for a subset of the provable cases for the
> sake of easy of implementation.