2013/2/9 Jonathan M Davis <jmdavisp...@gmx.com> > On Saturday, February 09, 2013 15:26:10 kenji hara wrote: > > 2013/2/9 kenji hara <k.hara...@gmail.com> > > > > > 2013/2/9 Jonathan M Davis <jmdavisp...@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