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

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

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

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

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

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

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