Bug 2864 – intra-module use of deprecated should be allowed

Andrei Alexandrescu wrote: > Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand() entirely from this release, but Walter pointed out it would break too much code. So I left rand() and rand_seed() as deprecated. Now I only left rand() deprecated so at least the static constructor works. I think the right fix for that is for the compiler to not complain about deprecated symbol usage if the usage is in the same module the deprecated symbol is defined in.

It should be left enabled if warnings are requested though, IMHO. I can see deprecating something and wanting to clean my own code of it easily. Would be embarrassing if my own code still used it. -[Unknown]

The problems are: - even when developing your own library, you'll likely want reminding if you inadvertently use one of your own deprecated entities - when you're ready to release a stable version of your product, you ought to be able to just delete everything that's deprecated and be done with it Perhaps better would be some form of 'deprecatedly public' as I suggested once.... http://www.digitalmars.com/d/archives/digitalmars/D/Suggestion_More_deprecation_features_73796.html

(In reply to comment #0) > Andrei Alexandrescu wrote: > > Ok, I've undeprecated rand_seed, sigh. I was hoping I'd eliminate rand() entirely from this release, but Walter pointed out it would break too much code. So I left rand() and rand_seed() as deprecated. Now I only left rand() deprecated so at least the static constructor works. > > I think the right fix for that is for the compiler to not complain about > deprecated symbol usage if the usage is in the same module the deprecated > symbol is defined in. Is this really necessary? It sounds like it could be done using private symbols and public deprecated symbols.

(In reply to comment #3) > > I think the right fix for that is for the compiler to not complain about > > deprecated symbol usage if the usage is in the same module the deprecated > > symbol is defined in. > > Is this really necessary? It sounds like it could be done using private > symbols and public deprecated symbols. Agreed. And I've heard no complains about this except in this ancient report.

Workaround suggested by @yebblies should be enough.