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


--- Comment #0 from Jonathan M Davis <jmdavisProg gmx.com> 2012-05-29 22:44:59
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



--- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2012-05-29 23:49:03 PDT ---
(In reply to comment #0)
[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



--- Comment #2 from Jonathan M Davis <jmdavisProg gmx.com> 2012-05-29 23:56:32
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


--- Comment #3 from bearophile_hugs eml.cc 2012-05-30 05:00:22 PDT ---
(In reply to comment #2)


 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


--- Comment #4 from art.08.09 gmail.com 2012-05-30 10:34:21 PDT ---
(In reply to comment #1)

 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



--- Comment #5 from Jonathan M Davis <jmdavisProg gmx.com> 2012-05-30 10:48:49
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


--- Comment #6 from timon.gehr gmx.ch 2012-07-10 13:49:59 PDT ---
*** 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