Pure and Structs

[dsimcha]

== Quote from dsimcha (dsimcha at 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.