== Quote from dsimcha ([email protected])'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.
