digitalmars.D.bugs - [Issue 2864] New: intra-module use of deprecated should be allowed
- d-bugmail puremagic.com (17/18) Apr 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2864
- d-bugmail puremagic.com (11/11) Apr 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2864
- d-bugmail puremagic.com (17/17) Aug 08 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2864
- d-bugmail puremagic.com (14/20) Feb 14 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2864
- d-bugmail puremagic.com (11/17) Feb 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=2864
http://d.puremagic.com/issues/show_bug.cgi?id=2864 Summary: intra-module use of deprecated should be allowed Product: D Version: 2.029 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: bugzilla digitalmars.com 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. --
Apr 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2864 unknown simplemachines.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |unknown simplemachines.org 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] --
Apr 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2864 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg iname.com 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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 08 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2864 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.com Platform|x86 |All Version|2.029 |D2Andrei Alexandrescu wrote:Is this really necessary? It sounds like it could be done using private symbols and public deprecated symbols. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
Feb 14 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2864 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 18:12:10 PST ---Agreed. And I've heard no complains about this except in this ancient report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
Feb 04 2013