[Suggestion] More deprecation features

[Robert Fraser]

Stewart Gordon Wrote:
> "Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
> > Idea 4 -- If you need to deprecate private imports, your modules are too
> > big.
> 
> You mean bloated with deprecated stuff that should've been deleted ages ago, 
> or what?
> 
> > Public imports seem to be sort of iffy to me anyway (except for an
> > "all" module), but is your idea that:
> >
> > module a;
> > public struct Foo { };
> > ----
> > module b;
> > deprecated public import a;
> > ----
> > module c;
> > import b;
> > Foo foo; // <-- deprecation error here
> 
> Yes.
> 
> > Then why can't module c just change it to:
> > ----
> > module c;
> > import a;
> > Foo foo;
> 
> Suppose I acquire the code of an application written using some library. 
> Now suppose that the library has been updated since the application was 
> written.  The library author wanted to deprecate some public imports, but 
> because D doesn't currently let you do this, removed them instead.  Then I 
> cannot compile the application without going through its modules working out 
> how to fix the masses of undefined symbols.  If the imports were merely 
> deprecated, I would need only to add the -d switch in the makefile or 
> whatever.

Can you explain a situation in which this would not be covered by 
deprecating the modules themselves rather than the public import 
thereof? 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.

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.