On 2011-03-30 17:05, dsimcha wrote: > On 3/30/2011 7:56 PM, bearophile wrote: > > Jonathan M Davis: > >> Andrei is currently against making range-based functions work with > >> opApply because of the resulting increase complexity of the > >> implementations. They were really meant for ranges, not opApply. That > >> doesn't necessarily mean that it's a guaranteed "we don't want to do > >> it," but it's definitely questionable. > > > > There is no "perfect design" here. I have suggested a compromise, where > > few basic functions (array(), walkLength()) work with every kind of > > iterable. Othrwise opApply becomes a third-class functionality and users > > need to write their own opApply-related functions. > > > > Bye, > > bearophile > > Agreed. Andrei's opinion is understandable if he thinks he'd have to > implement these features and has better things to do. I'd be willing to > do the implementation work if the relevant compiler bugs/enhancements > (2443, 4707, and maybe support for inlining delegates) get fixed so I > can do it right.
I don't think that it was just a question of having to implement it. It's a question of the complexity of the implementation. Having to duplicate a bunch of functions - or large portions of them - to get opApply to work with them increases their complexity. You'll have to talk to Andrei though if you want a better understanding of his opinion on the matter. - Jonathan M Davis
