[Suggestion] More deprecation features

[Koroskin Denis]

On Fri, 18 Jul 2008 04:19:25 +0400, Robert Fraser  
<fraserofthenight at gmail.com> wrote:

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

A better idea would be to declare the *module* as deprecated:

old_stuff.d:
~~~~~~~~~~~~
deprecated module old_stuff;
...