dmd 2.029 release

Don nospam at nospam.com
Wed Apr 22 00:12:04 PDT 2009


Daniel Keep wrote:
> 
> Michel Fortin wrote:
>> On 2009-04-21 11:18:39 -0400, Don <nospam at nospam.com> said:
>>
>>> Yes. Actually, marking a nested function as pure doesn't make much sense.
>>> It's entirely equivalent to moving it outside the function; a nested
>>> pure function shouldn't be able to access any members of the enclosing
>>> function, otherwise it's not pure. But DMD doesn't enforce that, and
>>> so it creates inefficient and possibly buggy code.
>> What about immutable local variables? A pure function can access
>> immutable globals, so it should be able to access immutable locals too.
>>
> 
> If you treat the nested function's context pointer as a pointer to a
> struct matching the stack layout, then you can have pure nested
> functions -- they have exactly the same semantics as a pure struct
> member function.
> 
>   -- Daniel

True, but that would mean that it'd be pretty useless. It's almost 
exactly the same as not marking it pure.
pure foo(int x)
{
   int y;
   pure int bar(int z) { return z*z; }

   int a= bar(2);
   y++;
   int b = bar(2); // has to recalculate bar(2), because y has changed.
}

---
The basic issue is that the situations where marking a nested function 
as 'pure' is a good idea, is extremely limited.
Compared to making it an external pure private function, with any 
desired immutable members passed as parameters, it has these advantages 
and disadvantages.
+ inaccessable to other functions in the same module.
+ can access immutable members in the outer function, without passing 
them as parameters.
- slower, since it needs a context pointer as well as a frame pointer.

I think those benefits are pathetic.


More information about the Digitalmars-d-announce mailing list