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: -------

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: -------

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: -------

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: -------

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: -------

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: -------