www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 678] New: should this be a bug??

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678

           Summary: should this be a bug??
           Product: D
           Version: 0.177
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: davidl 126.com


void[] t(){return null;}
void main()
{
        void* m;
        m=t().ptr;    //compiles
        m=t.ptr;      // fails, i'm worry about if let it through , maybe we
will have buggy code. but due to D's documentation this should be compiled
}


-- 
Dec 11 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


davidl 126.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|should this be a bug??      |should this be a bug??




------- Comment #1 from davidl 126.com  2006-12-11 23:32 -------
h3r3tic imo it shouldnt work... if it worked, one would assume it to work for
delegates as well. but delegates support the .ptr property so it couldnt work
with them.


-- 
Dec 11 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678





------- Comment #2 from davidl 126.com  2007-09-15 09:51 -------
previous code compiles with DMD 1.021, don't know if any ealier version fixes
the behavior, while the following ambiguous is related to this change
(mentioned by h3)
void[] t(){return null;}
class v
{
        void[] k(){return null;};
}
void main()
{
                void[] delegate() dg;
                auto inst= new v;
                dg= &inst.k;
                assert(dg().ptr is null);
                assert(dg.ptr is null);
        void* m;
        m=t().ptr;    //compiles
        m=t.ptr;      // fails, i'm worry about if let it through , maybe we
will have buggy code. but due to D's documentation this should be compiled
}


-- 
Sep 15 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


Rob Jacques <sandford jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandford jhu.edu




--- Comment #3 from Rob Jacques <sandford jhu.edu>  2009-08-03 19:22:04 PDT ---
Both examples compile in D 2.031.

Should this be marked as resolved?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley gmail.c
                   |                            |om




--- Comment #4 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-08-03 20:12:06 PDT ---
(In reply to comment #3)
 Both examples compile in D 2.031.
 
 Should this be marked as resolved?

The second example *compiles* but the second assertion fails. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


Witold Baryluk <baryluk smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk smp.if.uj.edu.pl


--- Comment #5 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-02-05
06:27:27 PST ---
The problem with this code is that compiler doesn't know if you ask for:
1) a pointer of the base of the void[] array returned from t (used as property)
2) or a pointer of the t function/delegatel

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
         AssignedTo|nobody puremagic.com        |bugzilla digitalmars.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=678


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #6 from bearophile_hugs eml.cc 2010-11-26 13:55:18 PST ---
This situations will be partially cleaned up when functions/delegates calls
will require ().

The specs need to specify what's the behaviour of using the .ptr of a  property
delegate that returns an array (or that returns anything that has a ptr field):

void main() {
     property int[] delegate() bar1 = { return [1, 2]; };
    struct Foo { int* ptr; }
     property Foo delegate() bar2 = { return Foo(); };
    auto x1 = bar1.ptr;
    auto x2 = bar2.ptr;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010