www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8162] New: [TDPL] -property fails to give an error when a property function is called with parens

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

           Summary: [TDPL] -property fails to give an error when a
                    property function is called with parens
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com



PDT ---
This code

struct R42
{
     property int front()  safe const pure nothrow
    {
        return 42;
    }


     property bool empty()  safe const pure nothrow
    {
        return false;
    }

    void popFront()  safe pure nothrow
    {
    }
}

void main()
{
    R42 r;
    auto e = r.empty();
}


shouldn't compile, since empty is a property and therefore must not compile
with parens per strict property enforcement as described in TDPL. _Not_ calling
popFront with parens _does_ result in an error with -property, but calling
either of the property functions _with_ parens doesn't. So -property seems to
be doing half of its job but not all of it. With -property,  property functions
should never be callable with parens, and non- property functions should never
be callable without them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162





[snip]
 shouldn't compile, since empty is a property and therefore must not compile
 with parens per strict property enforcement as described in TDPL. _Not_ calling
 popFront with parens _does_ result in an error with -property, but calling
 either of the property functions _with_ parens doesn't. So -property seems to
 be doing half of its job but not all of it. With -property,  property functions
 should never be callable with parens, and non- property functions should never
 be callable without them.
I can agree in basic, but I know a case which the strict property enforcement will cause problems. It is opDispatch. void main() { S s; assert(s.prop == 10); // s.prop is expected as property assert(s.func(1) == 2); // s.func is expected as member function } struct S { property auto opDislatch(string name, A...)(A args) { static if (name == "prop" && A.length==0) return 10; static if (name == "func" && A.length==1) return args[0] * 2; } } If strict property enforcement is implemented, S.opDispatch won't work anymore. Because property is not considered by overload resolution. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162




PDT ---
 If strict property enforcement is implemented, S.opDispatch won't work anymore.
 Because  property is not considered by overload resolution.
I believe that opDispatch already has the issue that you can't use property and non-property functions with it (IIRC someone on D.Learn was discussing that not too long ago). So, we probably need to do something special with opDispatch anyway. As it stands, strict property enforcement (as TDPL describes) doesn't work properly, and it should. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162


bearophile_hugs eml.cc changed:

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





 As it stands, strict property enforcement (as TDPL describes) doesn't work
 properly, and it should.
And I think the more time we wait, the less easy it becomes to fix such problems. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162


art.08.09 gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |art.08.09 gmail.com




 If strict property enforcement is implemented, S.opDispatch won't work anymore.
 Because  property is not considered by overload resolution.
This is already a problem; i had cases where i couldn't use opDispatch, because i needed both the property and "method" versions... It would be best if both property and non-property versions would be legal at the same time, at least for opDispatch. This bug has more serious consequences -- think properties that return callables -- 'o.property()' does not do what you expect it to do, instead you have to work-around with 'o.property()()', which doesn't really make sense. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 30 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162




PDT ---
 This bug has more serious consequences -- think properties that return
 callables -- 'o.property()' does not do what you expect it to do, instead you
 have to work-around with 'o.property()()', which doesn't really make sense.
That's one of the major reasons that property was introduced - to disambiguate when returning delegates. So, the fact that -property doesn't help with that at all is a huge indicator that there's a major problem with it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 30 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8162


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr gmx.ch



*** Issue 8372 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 10 2012