Re: Fun with range deprecations

[Fra via Digitalmars-d]

On Monday, 11 August 2014 at 22:59:34 UTC, H. S. Teoh via 
Digitalmars-d wrote:
So, a recent Phobos deprecation introduced a fun regression:
        https://issues.dlang.org/show_bug.cgi?id=13257

While the bug was filed specifically for the use case
range.splitter.map, the problem is actually much more general, 
and far
from obvious how to address.

First, let's consider the following setup.  Start with this 
example
range:

        struct MyRange(T) {
                // input range
                @property bool empty() { ... }
                @property T front() { ... }
                void popFront() { ... }

                // forward range
                @property MyRange save() { ... }

                // bidirectional range
                @property T back() { ... }
                void popBack() { ... }
        }

Suppose we write an algorithm that operates on ranges in 
general,
including MyRange. The current convention is to forward as many 
range
methods as possible, so that if you give it a bidi range, it 
will, where
possible, give you a wrapped bidirectional range. So we do this:

        auto myAlgo(R)(R range)
                if (isInputRange!R)
        {
                struct Result {
                        // input range methods
                        @property bool empty() { ... }
                        @property U front() { ... }
                        void popFront() { ... }

                        // N. B. if we got a forward range, and we can
                        // implement .save, then do so.
                        static if (isForwardRange!R &&
                                canDoForwardRange)
                        {
                                @property Result save() { ... }
                        }

                        // N. B. if we got a bidirectional range, and we
                        // can implement .back and .popBack, then do so.
                        static if (isBidirectionalRange!R &&
                                canDoBidirectionalRange)
                        {
                                @property U back() { ... }
                                void popBack() { ... }
                        }
                }
                return Result(...);
        }

Now suppose, for whatever reason, we decide that implement 
MyRange as a
bidirectional range was a bad idea, and we decide to deprecate 
it:

        struct MyRange(T) {
                ... // input & forward range API here

		deprecated("Use of MyRange as bidirectional range is now 
deprecated")
                {
                        @property T back() { ... }
                        void popBack() { ... }
                }
        }

Now the fun begins. Currently, isBidirectionalRange uses
is(typeof(...)) to check if .back and .popBack exist in target 
type.
So when myAlgo() checks MyRange, this check passes, because 
even though
.back and .popBack have been deprecated, they obviously still 
exist, so
they do have a valid type. So that check passes. Therefore, 
myAlgo()
will try to export a bidirectional interface in its result.

However, inside Result.back and Result.popBack, when it 
actually tries
to use MyRange.back and MyRange.popBack, the compiler throws up 
its
hands and say, Wait!! .back and .popBack are deprecated!!

Note that this happens *regardless* of whether .back and 
.popBack are
actually used by the user code that calls myAlgo(). This means 
that if
user code only ever uses forward range capabilities of 
myAlgo(), users
will *still* get irrelevant deprecation messages -- for 
bidirectional
range features that they never use! Furthermore, the only reason
myAlgo() added .back and .popBack which trigger the deprecation
messages, is because the is(typeof(...)) check tests positive 
for
bidirectional range support.

This problem, obviously, is not specific to bidirectional 
ranges, or,
for that matter, *any* range based code. It's a general problem 
with
wrapped types, of the form:

        struct Wrapped {
                deprecated void method();
        }

        struct Wrapper(T) {
                T t;
                static if (is(typeof(t.method())))
                {
                        void func() {
                                t.method();
                        }
                }
        }

The problem here is that t.method() is generic, and it has 
specifically
tested for the usability of t.method(), yet when it tries to 
actually
use t.method(), it hits a deprecation message. How is it 
supposed to
know if t.method() has been deprecated? Currently we have no
__traits(deprecated) test. And even if we did, this may not be 
the best
solution (are we going to now insert __traits(deprecated) all 
over
generic code, on the off-chance that some random user type 
somewhere
will get deprecated in the unforeseeable future?).

So the question now is: how do we deal with this issue? 
Currently, this
problem already exists in Phobos 2.067a, and random user code 
that calls
splitter(...).map(...) will hit this problem.

So far the following have been suggested, none of which seem
particularly satisfactory:

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?

2) Add a __traits(deprecated) or is(T == deprecated) test, and 
update
all affected sig constraints in Phobos to check for this. 
Doesn't sound
like an appealing solution.

3) Have std.algorithm.map specifically check for a specific 
overload of
std.algorithm.splitter, and omit .back and .popBack in that one 
case.
Very hackish, solves the immediate problem, but leaves the 
general
problem unsolved. User code that wraps around splitter in a 
similar way
to map will *still* be broken (even if they never actually use
bidirectional features).

4) Shorten the deprecation cycle of splitter. Doesn't even 
solve the
immediate problem, just shortens it, and still leaves the 
general
problem unsolved. User code that wraps around splitter is still 
broken
(even if they never actually use bidirectional features).

Since no obvious acceptable solution seems forthcoming, I 
thought we
should bring this to the forum for discussion to see if anyone 
has a
better idea.


T
Noob question... shouldn't __traits(compile) enable us to handle 
the situation correctly?