[Suggestion] More deprecation features

[Stewart Gordon]

"Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
news:g5onid$1s64$1 at digitalmars.com...
<snip>
> 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.

Effectively yes.  I think I've wanted to do this for SDWF on occasion.

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

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.

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

If that's the case, it's a bigger problem than just a public import.

Stewart.

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