www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8490] New: Global property calls do not work with auto expressions

reply d-bugmail puremagic.com writes:
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: -------
Aug 01 2012
next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 29 2012
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 04 2012