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