<div dir="ltr">2013/2/9 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">And why is it that the global function gets to be a setter property and the</span><br></div>
UFCS function doesn't? What's the advantage in choosing the UFCS function as<br>
the one that has to be a normal function which just happens to be called<br>
without parens (but could be called with them) over choosing the global getter<br>
property to be the one that's a function that can be called without parens?<br></blockquote><div><br></div><div>To get a balance between rule simplicity and actually possible use cases.<br></div><div><br></div><div style>
<div>In my long thought, I have found that @property annotation is not really necessary for UFCS getters (e.g. std.array.front). </div><div>After the implementation of "optional paranthesis" feature which described in DIP23, a use of UFCS getter will work as same as now - using left hand side of assignment (e.g. arr.front = value) and even getting address of returned ref (auto ptr = &arr.front) . Then, we can use a @property function defined in module level and has exactly one parameter as a module level setter without ambiguity. This is much reasonable benefit compared to the cost.</div>
<div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'd much rather see the global getter have to be declared without @property<br>
(and rely an the ability to be called without parens but be unable to enforce<br>
it).</blockquote><div><br></div><div style>I think it will introduce an inconsistency against method @property functions, as follows:</div><div style><br></div><div style>- Method property should have zero parameter for getter, or one parameter for setter.</div>
<div style>  Both should be annotated with @property.</div><div style>- Module level property should have zero parameter for getter, but MUST not be annotated with @property.</div><div style>  Module level property should have one parameter for setter and should be annotated with @property.<br>
</div><div style><br></div><div style>This is much complicated than my proposed sentence:</div><div> </div><div><span style="font-family:arial,sans-serif;font-size:14px">2. A @property may have EXACTLY ZERO or EXACTLY ONE parameter, without counting the implicit this parameter if at all.</span><br style="font-family:arial,sans-serif;font-size:14px">
<span style="font-family:arial,sans-serif;font-size:14px">The ZERO-parameter version is ALWAYS a getter, and the ONE-parameter version is ALWAYS a setter.</span><br style="font-family:arial,sans-serif;font-size:14px"><span style="font-family:arial,sans-serif;font-size:14px">There's no variadics, defaulted parameters, and such.</span><br style="font-family:arial,sans-serif;font-size:14px">
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">And I _definitely_ wouldn't want to set a precedence for front to be<br>

declared as a non-property function. It needs to be consistently called<br>
without parens to work in generic code, and if arrays are able to use front<br>
with parens, then we definitely risk a lot of range-based functions being<br>
written incorrectly due to the fact that far too often, range-based functions<br>
only end up being tested with arrays, and in that case, the parens wouldn't<br>
cause an error like they should. It wouldn't be caught until someone actually<br>
tried it with another type of range (possibly much later). Granted, the writer<br>
of the range-based function should have tested it better, but given that<br>
arrays are by far the most common type of range, I think that it's just asking<br>
for trouble to allow their front or back to be used with parens.<br></blockquote><div><br></div><div style>Sorry I cannot imagine an actual use case you are considering.</div><div style><br></div><div style>Kenji Hara</div>
</div></div></div>