http://d.puremagic.com/issues/show_bug.cgi?id=8490

           Summary: Global property calls do not work with auto
                    expressions
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-08-01 07:27:27 PDT ---
struct Foo { }
@property bool isTrue(Foo foo) { return true; }

void main()
{
    Foo[int] x = [1:Foo()];
    if (auto foo = 1 in x) {
        bool b = foo.isTrue;
    }
}

test.d(10): Error: no property 'isTrue' for type 'Foo'

-- 
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=8490


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Global property calls do    |Global property calls do
                   |not work with auto          |not work with pointers
                   |expressions                 |


--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-08-29 06:34:28 PDT ---
This is related to pointers not just auto expressions:

struct Foo { }
@property bool isTrue(Foo foo) { return true; }

void main()
{
    Foo* foo = new Foo;
    bool b = foo.isTrue;
}

-- 
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=8490


art.08.09@gmail.com changed:

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


--- Comment #2 from art.08.09@gmail.com 2012-08-29 15:11:31 PDT ---
(In reply to comment #1)
> This is related to pointers not just auto expressions:
> 
> struct Foo { }
> @property bool isTrue(Foo foo) { return true; }
> 
> void main()
> {
>     Foo* foo = new Foo;
>     bool b = foo.isTrue;
> }

   @property bool isTrue(ref Foo foo) { return true; }

should probably work, but the by-value version might be too dangerous to be allowed...

-- 
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=8490



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-08-29 15:44:48 PDT ---
Why dangerous? Normal method invocations work, so why shouldn't UFCS work?

-- 
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=8490



--- Comment #4 from art.08.09@gmail.com 2012-08-29 16:29:36 PDT ---
(In reply to comment #3)
> Why dangerous? Normal method invocations work, so why shouldn't UFCS work?

Having methods (what UFCS emulates) which implicitly create a copy of the object and operate on that copy would be confusing. Both for the interface user and the creator. The latter will be forgetting about the 'ref' while the former will not expect 'o.whatever' to copy 'o' and call 'whatever' using that private copy. Both issues would be bug sources.

Not introducing unsound features is easier than later removing 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=8490


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-08-29 16:36:05 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > Why dangerous? Normal method invocations work, so why shouldn't UFCS work?
> 
> Having methods (what UFCS emulates) which implicitly create a copy of the object and operate on that copy would be confusing. Both for the interface user and the creator. The latter will be forgetting about the 'ref' while the former will not expect 'o.whatever' to copy 'o' and call 'whatever' using that private copy. Both issues would be bug sources.
> 
> Not introducing unsound features is easier than later removing them...

Oh I see what's going on now, the pointer can't be passed because it would have to be dereferenced. I think this is invalid then, thanks.

-- 
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=8490


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-09-04 10:55:18 PDT ---
> Having methods (what UFCS emulates) which implicitly create a copy of the
object and operate on that copy would be confusing.

This already happens with structs and UFCS in general. e.g.

struct S {}

auto func(S s, int i) {...}

s.func(5);

makes as copy. So, I don't see that as a problem at all.

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