dmd 2.029 release

[Don]

Steven Schveighoffer wrote:
> On Wed, 22 Apr 2009 03:12:04 -0400, Don <nospam at nospam.com> wrote:
> 
>> 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.
> 
> What about treating nested functions of pure functions like a logical 
> grouping of statements within the function?  That is, when you call a 
> nested function inside a pure function, the call can't be optimized, but 
> any calls the nested function makes (to a global pure function) can be 
> optimized, and the nested function still provides the same guarantees 
> (cannot access any globals, must only call other pure functions), 
> however it can access and modify locals within the outer function.

That's exactly what my recent change (2804) did.

> I use nested functions a lot not as mini functions within a function but 
> as simple ways to avoid duplicating code everywhere in my function.
> 
> You probably couldn't allow taking a delegate of such a function either.

I've just submitted a patch (2695) which makes usage of function 
pointers and delegates safe within pure functions. Basically, you can 
take the delegate of a nested function, but you can't call it.
You could return it, but I believe that's OK, because it should become a 
closure.

I'm on a quest to make 'pure' usable in D <g>.