<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/1/25 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Friday, January 25, 2013 10:15:09 kenji hara wrote:<br>
> 1. Optional parentheses for normal functions should work shallowly IMO.<br>
> 2. Optional parentheses for property functions should not work. Applying ()<br>
> for property function name always applied to its returned value.<br>
><br>
> #1 is a ratification of current behavior. It allows the combination of UFCS<br>
> and removing redundant ()s.<br>
> #2 is a breaking change. If we need it, community consent is required.<br>
<br>
</div>I'd say that we should do both. It's ridiculous to accept parens on property<br>
functions, since the whole point is that they be used as if they were<br>
variables. They're _supposed_ to be illegal (though -property doesn't check<br>
for it right now like it's supposed to - it only checks whether parens are<br>
used on non-property functions). So, I don't think that there's any question<br>
that #2 needs to happen with @property (unless Walter's horrid plan gets put<br>
into effect and we lose @property entirely). And #1 seems reasonable enough.</blockquote><div><br></div><div>Two months ago, I've tried to implement the rule and posted an experimental pull request.</div><div><a href="https://github.com/D-Programming-Language/dmd/pull/1311">https://github.com/D-Programming-Language/dmd/pull/1311</a> <br>
</div><div><div><br></div><div>From that experience, we still need to define some behaviors of corner cases, even if the rule is applied.</div></div><div><br></div><div>One of them is getting an address of property function which returns ref.</div>
<div><br></div><div>@property ref int foo();</div><div>auto x = &foo;   // x is a function pointer, or an address of returned value?</div><div><br></div><div>This is the most sensible problem.</div><div>(a) If typeof(x) should be a function pointer, we need to use a utility function to get int*. </div>
<div>  </div><div>   ref identity(T)(ref T t) { return t; }</div><div>   int* p1 = &(identity(foo));</div><div>      // foo is evaluated to ref int in function argument,</div><div>      // and identity gets through the reference.</div>
<div><div>   int* p1 = &foo.identity;</div><div>      // with UFCS, parentheses can be removed.</div><div><br></div><div>   This is a real issue. In phobos, the ref-ness of front property is actually checked in std.range.moveFront.</div>
<div><br></div><div>(b) If typeof(x) should be a int*, we will lose the way to getting a function pointer of foo.</div></div><div>   That is more serious than (a). If we adopt this rule, we will *really* get lost the way to distinguish property functions and raw data fields. (Note that: In current typeof(foo) already returns int. So AddressExp is only one way to getting (normal|property) function information by its type.) From the view of meta-programming, I think this makes a serious flaw.</div>
<div><br></div><div>Kenji Hara</div></div></div></div>