Fun with range deprecations

[H. S. Teoh via Digitalmars-d]

On Tue, Aug 12, 2014 at 06:42:56PM +0000, Dicebot via Digitalmars-d wrote:
> On Monday, 11 August 2014 at 22:59:34 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >1) Make Wrapper.func() a template function, so that the deprecation
> >message is not triggered unless the user actually calls it (in which
> >case the deprecation message *should* be triggered). The problem is
> >that when the deprecation message *is* triggered, it comes from deep
> >inside Phobos, and users may complain, why did you export a
> >bidirectional range API if that support is already deprecated?
> 
> After some thinking about it I am leaning towards this option again.
> If there is some user code that relies on bidirectional API exposed
> then it probably should get deprecation warning after all.
> 
> I may change my mind again though :)

Well, it does seem to be the least evil among the other option, even if
it's not ideal!

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

On the positive side, if these "optional" range methods are templatized,
they will reduce template bloat in code that doesn't need to use them.
AFAIK, if you have a template struct with 10 methods, all 10 will get
instantiated when you instantiate the struct, even if you only ever use
3 of them in your code. So it seems to be a good thing to templatize the
"additional" methods like .save, .back, .popBack, .opIndex, which may
never get used if the user only ever needs the input range methods.

Note that this still doesn't fully solve the problem, because if you use
something like std.range.InputRangeObject on the result of splitter(),
then it's going to spew deprecation messages no matter what, because
InputRangeObject uses reflection to determine whether to export .back
and .popBack.

So basically, deprecation and generic code don't seem to get along very
well. :-(


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.