Jump to page: 1 2
Thread overview
[Issue 9062] New: AddrExp should distinguish the existence of property resolution.
Nov 23, 2012
Kenji Hara
Nov 23, 2012
Kenji Hara
Nov 23, 2012
dawg@dawgfoto.de
Nov 23, 2012
Kenji Hara
Nov 23, 2012
timon.gehr@gmx.ch
Nov 23, 2012
timon.gehr@gmx.ch
Nov 23, 2012
Kenji Hara
Nov 23, 2012
timon.gehr@gmx.ch
Nov 23, 2012
Kenji Hara
Nov 23, 2012
timon.gehr@gmx.ch
Nov 25, 2012
Kenji Hara
Nov 27, 2012
David Nadlinger
Dec 05, 2012
Walter Bright
Dec 06, 2012
Kenji Hara
Dec 06, 2012
Walter Bright
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
November 23, 2012
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: -------
« First   ‹ Prev
1 2