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



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                 |



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





 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




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






 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



16:36:05 PDT ---




 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



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