http://d.puremagic.com/issues/show_bug.cgi?id=9601
--- Comment #7 from Maxim Fomin <[email protected]> 2013-02-27 09:37:52 PST --- (In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #0) > > > The idea is to make created delegate data pointer referring to a valid D > > > object > > > just like for class member function. > > > > Since creation delegate data pointer points to valid memory forgetting about > > tricks to deliberatly break it. Problem may come when i.e. class destructor > > references such object which was collected already by GC. But pointer > > should be > > reset to null. This actually is a problem of class destructor synchronizing. > > Are you targeting at this problem? > > No. I'm targeting the problem when delegate's outer scope is destroyed and the > problem of determining that the delegate will live "forever" (no "destroyable" > outer scope). See example suggested in my previous post. I see. This should have been clarified in the very first comment. > > > Once it will be implemented the only "raw" delegates would be struct > > > member > > > function delegates? which are used rarely and can easily be avoided. > > > > If such delegate references this struct pointer it may lead to trouble. > > Otherwise what is specific to struct delegates? > > Yes, struct pointer delegates will still be troubles unless D struct will > contain regular D object hidden fields defining it being a "struct object". I > see no good solution for this problem now. But as I have never meet with such > difficulties I don't think it is near as high priority issue as closure > delegates. Actually there is issue 9352. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
