www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9062] New: AddrExp should distinguish the existence of property resolution.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062

           Summary: AddrExp should distinguish the existence of property
                    resolution.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: k.hara.pg gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg gmail.com> 2012-11-22 19:31:04 PST ---
In this case, p is an address of g, or function pointer to foo?

  int g;
   property ref int foo() { return g; }
  auto p = &foo;

Until now, &foo always returns function pointer. If we want to get &g, we could
write as like:

  auto p = &foo();  // call foo first, then get an address of return value

But, if  property would be implemented more strictly, the syntax foo() will be
disallowed. In other words, getting &g from &foo will be impossible. It is a
serious flaw.

----

To resolve the problem, I'd like to propose a small special syntax: &(foo).
If AddrExp has a parenthesized expression, a property function in the operand
will be resolved to property call.

  pragma(msg, typeof( & foo  ));  // will print "int function()  property ref"
  pragma(msg, typeof( &(foo) ));  // will print "int*"

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 22 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #1 from github-bugzilla puremagic.com 2012-11-22 22:24:20 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/2897ca8807d6ab54fc2c983325104b96d1bda10e
fix Issue 9062 - AddrExp should distinguish the existence of property
resolution

https://github.com/D-Programming-Language/phobos/commit/1ce5ca470a4520d1c3956e14ec3e8dfb4fcd907f
Merge pull request #966 from 9rnsr/fix9062

Supplemental fix for Issue 9062 - AddrExp should distinguish the existence of
property resolution

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #2 from Kenji Hara <k.hara.pg gmail.com> 2012-11-22 22:57:34 PST ---
https://github.com/D-Programming-Language/dmd/pull/1310

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg dawgfoto.de


--- Comment #3 from dawg dawgfoto.de 2012-11-23 03:30:57 PST ---
If  property is all about equivalence of fields and accessors, then &foo should
not return a function pointer. IMHO obtaining the funtion pointer should be the
special case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #4 from Kenji Hara <k.hara.pg gmail.com> 2012-11-23 04:57:35 PST ---
(In reply to comment #3)

 If  property is all about equivalence of fields and accessors, then &foo should
 not return a function pointer.


Then, there is no way to get a function pointer from property function, right?



 IMHO obtaining the funtion pointer should be the
 special case.


std.traits.FunctionTypeOf!(property_func) is a special case?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr gmx.ch


--- Comment #5 from timon.gehr gmx.ch 2012-11-23 05:00:33 PST ---
Property functions should always be called regardless of context.

int g;
 property ref int foo() { return g; }

pragma(msg, typeof( & foo  ));  // will print "int*"
pragma(msg, typeof( &(foo) ));  // will print "int*"

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #6 from timon.gehr gmx.ch 2012-11-23 05:04:00 PST ---
(In reply to comment #4)

 (In reply to comment #3)

 If  property is all about equivalence of fields and accessors, then &foo should
 not return a function pointer.


 
 Then, there is no way to get a function pointer from property function, right?
 ...


()ref => foo

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #7 from Kenji Hara <k.hara.pg gmail.com> 2012-11-23 05:32:10 PST ---
(In reply to comment #6)

 Then, there is no way to get a function pointer from property function, right?
 ...


 
 ()ref => foo


It looks like a lambda. Is it same as this?

  ref __lambda() { return foo; }

But, on the return statement, foo is translated to foo(). It seems not
possible.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #8 from timon.gehr gmx.ch 2012-11-23 05:41:30 PST ---
(In reply to comment #7)

 (In reply to comment #6)

 Then, there is no way to get a function pointer from property function, right?
 ...


 
 ()ref => foo


 
 It looks like a lambda. Is it same as this?
 
   ref __lambda() { return foo; }
 


Yes, it is the same as &__lambda, where __lambda is

static ref __lambda() { return foo; }

(the fact that the parser chokes on ref-qualified function/delegate literals
and function/delegate types is another bug.)


 But, on the return statement, foo is translated to foo(). It seems not
 possible.


&__lambda is a function pointer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #9 from Kenji Hara <k.hara.pg gmail.com> 2012-11-23 06:06:46 PST ---
(In reply to comment #8)
[snip]

OK, I understood what you say. But implementing it in library might be much
difficult...

---
// An experimental implementation of timon's idea.
template PropertyTypeOf(alias prop)
{
    auto ref wrapper()(){ return prop(); }
    alias PropertyTypeOf = typeof(&wrapper!());
}

/* property*/ int foo()  trusted nothrow { return 10;}
pragma(msg, PropertyTypeOf!foo);
// -> int function() nothrow  safe  (not  trusted)

void main()
{
    struct S { /* property*/ string bar() pure { return ""; } }
    pragma(msg, PropertyTypeOf!(S.bar));
    // -> Error...
}
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #10 from timon.gehr gmx.ch 2012-11-23 06:54:28 PST ---
(In reply to comment #9)

 (In reply to comment #8)
 [snip]
 
 OK, I understood what you say. But implementing it in library might be much
 difficult...
 
 ---
 // An experimental implementation of timon's idea.
 template PropertyTypeOf(alias prop)
 {
     auto ref wrapper()(){ return prop(); }
     alias PropertyTypeOf = typeof(&wrapper!());
 }
 
 /* property*/ int foo()  trusted nothrow { return 10;}
 pragma(msg, PropertyTypeOf!foo);
 // -> int function() nothrow  safe  (not  trusted)
 
 void main()
 {
     struct S { /* property*/ string bar() pure { return ""; } }
     pragma(msg, PropertyTypeOf!(S.bar));
     // -> Error...
 }
 ---


I am not sure what you are trying to do here. Anyways, the following should
work:

template PropertyTypeOf(alias prop) {
    alias PropertyTypeOf = typeof(()auto ref=>prop);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #11 from Kenji Hara <k.hara.pg gmail.com> 2012-11-25 01:51:06 PST
---
(In reply to comment #10)

 I am not sure what you are trying to do here. Anyways, the following should
 work:
 
 template PropertyTypeOf(alias prop) {
     alias PropertyTypeOf = typeof(()auto ref=>prop);
 }


My try is an emulation of your idea. I found two problems at least.

1. In a way that uses template function attribute deduction, getting the
 trusted attribute is impossible, because it is deduced to  safe.

2. Cannot get function type from member property function, because of 'need
this' error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 25 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at


--- Comment #12 from David Nadlinger <code klickverbot.at> 2012-11-27 10:50:27
PST ---
I would not worry to much about  trusted: In my » trusted considered harmful«
thread from a while back
(http://forum.dlang.org/thread/blrglebkzhrilxkbprgh forum.dlang.org), nobody
could come up with a reason for keeping it part of the interface. I just didn't
get around to writing a DIP resp. implementing it in DMD yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 27 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #13 from Walter Bright <bugzilla digitalmars.com> 2012-12-05
15:30:19 PST ---
C++ has one special case where (e) means something different from e. (Few
people know  that case exists.)

Adding such to D makes me very nervous. I think it's a sound principle that any
expression can be parenthesized without altering its meaning, it's important
for anything that generates source code (like mixins are wont to do).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #14 from Kenji Hara <k.hara.pg gmail.com> 2012-12-05 16:26:04 PST
---
(In reply to comment #13)

 C++ has one special case where (e) means something different from e. (Few
 people know  that case exists.)
 
 Adding such to D makes me very nervous. I think it's a sound principle that any
 expression can be parenthesized without altering its meaning, it's important
 for anything that generates source code (like mixins are wont to do).


It's sure. But, &propfunc is one of the key point for the more property
enforcement.

- If &propfunc returns an address of returned value, all function related meta
templates will be broken (e.g. FunctionTypeOf).
- If &propfunc returns a function pointer of propfunc, all semantics are kept
intact. But, to get an address of returned value from propfunc will become
impossible in range of using built-in-language features.

I have thought a library solution, but this is ugly to me.

import std.algorithm : move;
    T identity(T)(    T t) { return move(t); }
ref T identity(T)(ref T t) { return t; }

int g;
 property ref int propfunc() { return g; }
void main() {
    auto p1 = &propfunc;            // p1 is function pointer
    auto p2 = &identity(propfunc);  // p2 is int*
    // identity(propfunc) makes an expression,
    // then getting an address of returned value can be succeeded.
    assert(p2 == &g);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 05 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9062



--- Comment #15 from Walter Bright <bugzilla digitalmars.com> 2012-12-05
16:37:04 PST ---
I understand the ambiguity issue, and I am not proposing a solution. I'm just
arguing against the e and (e) solution as (perhaps) causing more ambiguity
problems.

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