Fun with range deprecations

[H. S. Teoh via Digitalmars-d]

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

-- 
Маленькие детки - маленькие бедки.