On Wed, Aug 13, 2014 at 01:10:36AM +0000, Dicebot via Digitalmars-d wrote: > On Tuesday, 12 August 2014 at 19:15:48 UTC, H. S. Teoh via Digitalmars-d > wrote: > >It does raise the question, though: should *all* range algos that > >return range wrappers that optionally forward functionality like > >forward range or bidirectional range functionality, be templatized? > >Obviously, we must always expose an input range API since that's the > >minimum functionality; but should all forward / bidirectional / > >random access / length methods be templatized? Otherwise this story > >will just repeat itself in the future, when something else needs to > >have, say, .length deprecated, or .opIndex, etc.. > > I think it is ok to go with templatization as default deprecation > handling approach but just changing all signatures for the sake of > consistency is not worth it - not until you actually need to deprecate > stuff. > > Lets wait a few days if any new ideas appear on this topic and proceed > with this solution.
Speaking of which, should this only be done for std.algorithm.map, or should we also templatize the other algos that export a bidirectional interface, on the off chance that somebody will try to use splitter with them? T -- Маленькие детки - маленькие бедки.
