[dmd-beta] D 1.075 and 2.060 betas 2

[kenji hara]

2012/7/31 Andrei Alexandrescu <andrei at erdani.com>:
> On 7/30/12 11:03 AM, Don Clugston wrote:
>>
>> On 30 July 2012 16:28, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>>
>>> On 7/30/12 10:27 AM, David Simcha wrote:
>>>>
>>>>
>>>> So is http://d.puremagic.com/issues/show_bug.cgi?id=8428  officially a
>>>> wontfix for this release?
>>>
>>>
>>>
>>> I think it's quite important we fix that one and its ilk.
>>
>>
>> Bug 5939 seems to be a Phobos design flaw, and this one is probably
>> related.
>> Unfortunately, I don't think we can fix the problem other than by
>> ripping all Voldemort types out of Phobos. Voldemort Types now appear
>> to be a concept that has tragically flawed semantics, and also has
>> poor performance (see
>> http://d.puremagic.com/issues/show_bug.cgi?id=5939). Removing them
>> would be a big change to make this late in a release cycle.
>> I don't know what to do here.
>
>
> OK, let's step back for just a second here.
>
> The first response to
> https://github.com/D-Programming-Language/phobos/pull/728 is it reflects a
> problem with the compiler.
>
> My conjecture (and please correct me if I'm wrong) is there should be no
> difference between a Voldemort static struct (emphasis on STATIC, which is
> not currently used in map) and a classic struct defined outside map. I'm
> saying this because I see no difference in what state is available and how
> code would be generated between the two. It's a simple name visibility
> issue.
>
> If that's correct, the fix in
> https://github.com/D-Programming-Language/phobos/pull/728 should simply add
> "static" to the Voldemorts, and implement the same functionality that it's
> currently implementing.

Unfortunately no. 'static nested struct' never have any frame pointers, so

auto map(alias pred, Range)(Range r) {
  static struct Result {
    .. auto front() { return pred(...); }
  }
}

if pred is a nested function and requires its frame pointer to call
it, Result cannot access it.

> Longer term, it has become obvious to me that we need a clear and simple
> mechanism for a function to save another function passed by alias, even if
> that function holds state. That must happen regardless of interaction with
> Voldemort types. We must have a mean do e.g. define a scope delegate that
> holds the alias function and is able to call it. This has been a
> long-standing problem that we've avoided in limited cases by relying on the
> built-in frame pointer.

The fundamental problem is the same as this.

Issue 5710 - cannot use delegates as parameters to non-global template
http://d.puremagic.com/issues/show_bug.cgi?id=5710


Kenji Hara