Thread overview
[Issue 9601] New: Make regular D objects on closures
Feb 27, 2013
Denis Shelomovskij
Feb 27, 2013
Maxim Fomin
Feb 27, 2013
Denis Shelomovskij
Feb 27, 2013
Maxim Fomin
Feb 27, 2013
Maxim Fomin
Feb 27, 2013
Denis Shelomovskij
Feb 27, 2013
Denis Shelomovskij
Feb 27, 2013
Maxim Fomin
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601

           Summary: Make regular D objects on closures
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: verylonglogin.reg@gmail.com


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 12:57:11 MSK ---
The idea is to make created delegate data pointer referring to a valid D object just like for class member function.

It will allow passing closure delegate to functions where such objects are expected and controlling/watching delegate lifetime.

Once it will be implemented the only "raw" delegates would be struct member function delegates? which are used rarely and can easily be avoided.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #1 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-27 05:20:41 PST ---
(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.
> 
> It will allow passing closure delegate to functions where such objects are expected and controlling/watching delegate lifetime.
> 
> Once it will be implemented the only "raw" delegates would be struct member function delegates? which are used rarely and can easily be avoided.

Please elaborate on "to make created delegate data pointer referring to a valid D object just like for class member function". I see no point here since it is always possible to do:

delegate dg = ...;
dg.ptr = whatever is valid - class for member-function, frame for non-member
one
dg()

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #2 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 19:51:10 MSK ---
(In reply to comment #1)
> Please elaborate on "to make created delegate data pointer referring to a valid D object just like for class member function".

As it looks like a proper way to allow "controlling/watching delegate lifetime" as I wrote. And such ability is essential to fix e.g. Phobos Issue 9603 and make a small but fundamental step forward to working signals in D. Also see Issue 9602.

> I see no point here since it is
> always possible to do:
> 
> delegate dg = ...;
> dg.ptr = whatever is valid - class for member-function, frame for non-member
> one
> dg()

I do not understand you example at all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #3 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-27 08:57:01 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > Please elaborate on "to make created delegate data pointer referring to a valid D object just like for class member function".
> 
> As it looks like a proper way to allow "controlling/watching delegate lifetime" as I wrote. And such ability is essential to fix e.g. Phobos Issue 9603 and make a small but fundamental step forward to working signals in D. Also see Issue 9602.
> 

You probably mean data pointer of delegate since delegate does not have lifetime. Still do not understand what exactly you are proposing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #4 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-27 09:05:30 PST ---
(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?

> It will allow passing closure delegate to functions where such objects are expected and controlling/watching delegate lifetime.

How do you suggest to pass information within delegate about data lifetime? Or what mechanism (in addition to GC) would ensure that?

> 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #5 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 20:09:50 MSK ---
(In reply to comment #3)
> You probably mean data pointer of delegate since delegate does not have lifetime.

I propose to define an "object" delegate's lifetime to be its data pointer lifetime.

> Still do not understand what exactly you are proposing.

OK. I added an example, see Comment 2 Issue 9603.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #6 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-27 20:21:58 MSK ---
(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.

> > It will allow passing closure delegate to functions where such objects are expected and controlling/watching delegate lifetime.
> 
> How do you suggest to pass information within delegate about data lifetime? Or what mechanism (in addition to GC) would ensure that?

This is trivial. When creating a closure allocate a special D class instead, that's all. I.e. add a few hidden D object fields before closure data. We will have something like member function delegate then.

> > 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 27, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9601



--- Comment #7 from Maxim Fomin <maxim@maxim-fomin.ru> 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: -------