[Suggestion] More deprecation features

[Robert Fraser]

Stewart Gordon Wrote:

> "Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
> news:g5ofbp$teb$1 at digitalmars.com...
> <snip excessive quoting>
> > All good ideas, but I fear that it's simply too much complication to make 
> > it
> > worth doing.
> 
> If you consider each of my ideas individually, _then_ which do you think are 
> simple enough to be worth doing?
> 
> Stewart.
> 
> -- 
> My e-mail address is valid but not my primary mailbox.  Please keep replies 
> on the 'group where everybody may benefit. 
> 

Idea 1 -- A workaround has already been posted for that one.

Idea 2-- I don't get this one. By "callback" do you mean deprecating the 
virtualitry/overridability of a function. I don't think I've ever needed to do 
that.

Idea 3 -- Okay, that one (deprecating modules) is cool enough; I'm down.

Idea 4 -- If you need to deprecate private imports, your modules are too 
big. 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

Then why can't module c just change it to:
----
module c;
import a;
Foo foo;

Unless the public import was exposing some internal functionality...? It just
seems like bad design in the first place if you need this.