Partial modification of DIP23 to allow module level property

[Jonathan M Davis]

On Saturday, February 09, 2013 15:26:10 kenji hara wrote:
> 2013/2/9 kenji hara <k.hara.pg at gmail.com>
> 
> > 2013/2/9 Jonathan M Davis <jmdavisProg at gmx.com>
> > 
> >> And I _definitely_ wouldn't want to set a precedence for front to be
> > 
> > declared as a non-property function. It needs to be consistently called
> > 
> >> without parens to work in generic code, and if arrays are able to use
> >> front
> >> with parens, then we definitely risk a lot of range-based functions being
> >> written incorrectly due to the fact that far too often, range-based
> >> functions
> >> only end up being tested with arrays, and in that case, the parens
> >> wouldn't
> >> cause an error like they should. It wouldn't be caught until someone
> >> actually
> >> tried it with another type of range (possibly much later). Granted, the
> >> writer
> >> of the range-based function should have tested it better, but given that
> >> arrays are by far the most common type of range, I think that it's just
> >> asking
> >> for trouble to allow their front or back to be used with parens.
> > 
> > Sorry I cannot imagine an actual use case you are considering.
> 
> Ah... do you consider this case?
> 
> import std.array : front;
> int delegate()[] eventHandlers;
> auto result = eventHandlers.front(); // want to _call_ eventHandlers[0]
> 
> Indeed, under the my proposal, typeof(result) becomes `int delegate()`, not
> `int`.
> 
> Hmmmm.....

That and the fact that if front isn't actually a property, then you can do 
stuff like this:

auto func(R)(R range)
    if(isForwardRange!R)
{
    auto f = range.front();
    //...
    return blah;
}

That code would then happily compile with arrays but fail with every other 
type of range. But since arrays are the most common type of range, it seems 
fairly common for people to test range-based functions with just arrays, and 
so it becomes very easy for people write code which is supposed to be range-
based but only works with arrays.

But the delegate example does make it much worse, because then range-based 
functions wouldn't be able to rely on front() calling the callable returned by 
front in the cases where front returns a callable, since that would only work 
with ranges which weren't arrays. Optional parens in generic code using a 
generic API is just begging for trouble. Any property in such an API needs to 
actually be @property so that it can't be called with parens and so that if it 
_is_ called with parens, it's attempted to use the parens on the return value.

- Jonathan M Davis