[Suggestion] More deprecation features

[Stewart Gordon]

"Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
news:g5qo45$22q6$1 at digitalmars.com...
<snip>
> Can you explain a situation in which this would not be covered by
> deprecating the modules themselves rather than the public import
> thereof?

Huh?  If you could deprecate modules without deprecating imports of them, 
then what would deprecating a module do at all?

You seem to be completely missing the point of deprecated imports.

Scenario 1:

Module A has a public import of module B.  Both modules are in the same 
library.  An application using the library imports module A, and while at it 
uses something in B.

The library author then decides that A should not publicly import B after 
all.  Deprecating B is not an option, as B is still needed - all that's 
wanted is to get it out of what comes with importing A.  The right course of 
action is therefore to deprecate A's import of B.  The application can still 
use B, it just needs to import it directly.  Meanwhile, the application can 
still be compiled using -d, since doing so activates the deprecated import.

Module A might also itself use something in B, in which case it can 
privately import B in addition to the deprecated public import.

Scenario 2:

Module A contains some deprecated, no longer maintained functions that 
depend on module B in the same library.  It's time to deprecate B. 
Obviously, A needs to keep its import of B so that A's deprecated functions 
can still work.  It does this by using a deprecated import.

The point is to support the principle that deprecated stuff can still depend 
on other deprecated stuff, for good reasons.  Here, the principle is applied 
twice: the deprecated functions in A depend on A's deprecated import of B, 
which in turn depends on deprecated module B.

A non-deprecated import of B would, OTOH, be an illegal dependency of 
something non-deprecated on something deprecated.

> Public imports in general seem like a very bad code design for an
> API to me. They're nice to have in the language (for internal stuff that's
> selectively publicly imported or "all" modules), but publicly importing an
> entire module for your API seems like a bad decision.

That's exactly why someone might want to deprecate such a decision.

> There's a workaround, anyway. Just privately import it and declare
> deprecated aliases to the members of the public import that you want to
> export.

That would alter the fully qualified names of the imported symbols....

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.