digitalmars.D.bugs - [Issue 7041] New: [PATCH] Add -di option to show deprecated errors as warnings
- d-bugmail puremagic.com (24/24) Dec 01 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (34/36) Feb 02 2012 The problem for me is, the way deprecated works now it's completely usel...
- d-bugmail puremagic.com (15/15) Feb 04 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (19/28) Feb 06 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (9/9) Apr 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (8/13) Apr 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (11/11) Nov 13 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7041
- d-bugmail puremagic.com (6/6) Jan 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7041
http://d.puremagic.com/issues/show_bug.cgi?id=7041 Summary: [PATCH] Add -di option to show deprecated errors as warnings Product: D Version: D1 & D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: llucax gmail.com PST --- The new option -di treats deprecation errors as informational warnings, just like -wi show warnings as informational messages without triggering errors. This would enable users to have a better update path from deprecated features, as they can be reminded (annoyed) with warnings but they can still compile their code. Patches available as a pull request in Github: https://github.com/D-Programming-Language/dmd/pull/248 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 01 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7041 2012-02-02 04:07:32 PST ---We already have so many options for deprecation and warnings, I am hard pressed to agree that adding more will help more than just add complexity.The problem for me is, the way deprecated works now it's completely useless for our workflow at least. We have programs that use libraries, those libraries get updated often and sometimes things are deprecated. If the programs are compiled with -d, you never get noticed about when something is deprecated, but when they were actually removed, then you have to give immediate attention to fix that part of the code, which might not be what you want. If programs are compiled without -d, then you get an error whenever something is deprecated, then you have to give immediate attention to fix that part of the code, which might not be what you want. This forces you to change your priorities. Sometimes I need to update a library because I need to use a new feature, but I have other priorities than fixing all the deprecation errors. For me the whole thing about deprecation is to *ease* the update path, not to force it. If I want to force it, I just remove the stuff and that's it. I think options are a matter of taste, I'm used to GCC so I can manage several hundreds of options (and I even like the flexibility). What are you scared about having more options? Are you concerned about complexity in code or just about people being scared about dmd help message being too long? If is the former, I think the patch makes the code simpler with the introduction of the deprecation() function. If is the later, you could show a simplified help and have an option to show the full help (--advanced-help or whatever). Also I wouldn't mind *at all* making deprecation warnings by default if you don't want to add more switches, or adding them to -wi or whatever, I just think the current situation with deprecation is just the worse possible. That said, I still would appreciate having the option of making deprecation errors (because sometimes is useful to use it as a commit hook or some other automatic testing). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 02:06:29 PST --- More and more switches for is it a warning? is it an error? makes for a rat's nest of confusion. I don't find the gcc example of thousands (!) of switches to be an example to emulate. Remember, each switch adds a burden of testing and documenting as well. The workflow is designed to ignore them until you're ready to fix them, then just fix the lot in one go. Each one should be trivial to do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 2012-02-06 09:51:22 PST ---More and more switches for is it a warning? is it an error? makes for a rat's nest of confusion. I don't find the gcc example of thousands (!) of switches to be an example to emulate. Remember, each switch adds a burden of testing and documenting as well.Did you see this part of the comment?Also I wouldn't mind *at all* making deprecation warnings by default if you don't want to add more switches, or adding them to -wi or whatever, I just think the current situation with deprecation is just the worse possible.The workflow is designed to ignore them until you're ready to fix them, then just fix the lot in one go. Each one should be trivial to do.That means changing the compilation flags, that usually means changing the build system, and the build system usually is in the VCS, and makes no sense to either changing the build system all the time each time something is depracated, or having to ignore changes in the build system, because some change might have to be really committed. And sometimes changes are not trivial at all. Anyway, I can understand that you don't want to add more options (well, not really, but I can accept it, is not that I have an option anyway :), but believe me, there are other valid and good workflows, I don't think the compiler should force the developers to use a particular workflow for this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 06 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 2012-04-25 04:43:27 PDT --- Please see this pull request: https://github.com/D-Programming-Language/dmd/pull/908 It only includes the patch adding the deprecation() function. I think is good independently of the discussion about adding deprecations as warnings. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 2012-04-25 04:58:58 PDT ---Please see this pull request: https://github.com/D-Programming-Language/dmd/pull/908 It only includes the patch adding the deprecation() function. I think is good independently of the discussion about adding deprecations as warnings.Pull request for dmd-1.x branch: https://github.com/D-Programming-Language/dmd/pull/909 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 25 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 Leandro Lucarella <leandro.lucarella sociomantic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED 2012-11-13 10:51:08 PST --- https://github.com/D-Programming-Language/dmd/pull/1185 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 13 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7041 2013-01-03 12:28:28 PST --- *** Issue 9221 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 03 2013