<div dir="ltr"><div>2013/2/9 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><br></div><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=""><div class="h5">On Saturday, February 09, 2013 15:26:10 kenji hara wrote:<br>
> 2013/2/9 kenji hara <<a href="mailto:k.hara.pg@gmail.com">k.hara.pg@gmail.com</a>><br>
><br>
> > 2013/2/9 Jonathan M Davis <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>><br>
> ><br>
> >> And I _definitely_ wouldn't want to set a precedence for front to be<br>
> ><br>
> > declared as a non-property function. It needs to be consistently called<br>
> ><br>
> >> without parens to work in generic code, and if arrays are able to use<br>
> >> 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<br>
> >> functions<br>
> >> only end up being tested with arrays, and in that case, the parens<br>
> >> wouldn't<br>
> >> cause an error like they should. It wouldn't be caught until someone<br>
> >> actually<br>
> >> tried it with another type of range (possibly much later). Granted, the<br>
> >> 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<br>
> >> asking<br>
> >> for trouble to allow their front or back to be used with parens.<br>
> ><br>
> > Sorry I cannot imagine an actual use case you are considering.<br>
><br>
> Ah... do you consider this case?<br>
><br>
> import std.array : front;<br>
> int delegate()[] eventHandlers;<br>
> auto result = eventHandlers.front(); // want to _call_ eventHandlers[0]<br>
><br>
> Indeed, under the my proposal, typeof(result) becomes `int delegate()`, not<br>
> `int`.<br>
><br>
> Hmmmm.....<br>
<br>
</div></div>That and the fact that if front isn't actually a property, then you can do<br>
stuff like this:<br>
<br>
auto func(R)(R range)<br>
    if(isForwardRange!R)<br>
{<br>
    auto f = range.front();<br>
    //...<br>
    return blah;<br>
}<br>
<br>
That code would then happily compile with arrays but fail with every other<br>
type of range. But since arrays are the most common type of range, it seems<br>
fairly common for people to test range-based functions with just arrays, and<br>
so it becomes very easy for people write code which is supposed to be range-<br>
based but only works with arrays.<br>
<br>
But the delegate example does make it much worse, because then range-based<br>
functions wouldn't be able to rely on front() calling the callable returned by<br>
front in the cases where front returns a callable, since that would only work<br>
with ranges which weren't arrays. Optional parens in generic code using a<br>
generic API is just begging for trouble. Any property in such an API needs to<br>
actually be @property so that it can't be called with parens and so that if it<br>
_is_ called with parens, it's attempted to use the parens on the return value.</blockquote><div> </div></div></div><div class="gmail_extra"><div>It makes sense... Thanks.<br></div><div><br></div><div style>Kenji Hara</div>
</div></div>