Partial modification of DIP23 to allow module level property

[kenji hara]

2013/2/9 Jonathan M Davis <jmdavisProg at gmx.com>

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


It makes sense... Thanks.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130209/308f36b0/attachment.html>