On Wednesday, November 13, 2013 20:13:43 Dicebot wrote: > On Wednesday, 13 November 2013 at 19:02:22 UTC, Jonathan M Davis > > wrote: > > That would actually be a _big_ problem for code > > maintainability. The same > > compiler binary _must_ be able to compile exactly the same set > > of programs no > > matter when it's used. I should be able to compile exactly the > > same set of > > programs with a particular compiler binary ten years from now > > as I can today. > > Anything else will be a huge problem for real world > > environments that use the > > same compiler for years at a time. It's not always an option to > > update the > > code or the compiler, and even if it is and even if you do > > update the code and > > the compiler, you need to be able to reproduce old builds, and > > that won't work > > if deprecated symbols suddenly stop working just because the > > date changed. > > What about connecting it to date of compiler release? That will > fix the issue and does not change much for the original proposal.
Not necessarily a bad idea, but again, Walter isn't going to go for complicating deprecated any further (we're arguably lucky to have what we've got), and given that you need to take the time to go and remove the deprecated symbol manually anyway, I don't think that it would really save you anything. With the current scheme, you can simply mark the symbol as deprecated and then remove it manually at some later date without having to do any other manual steps in between (unless you want to have the symbol undocumented but still there for some period of time, which adds one manual step). And since you really shouldn't be deprecating stuff all that frequently anyway, I don't think that a little extra work matters all that much. > > And -w does _not_ turn deprecation warnings into errors (and I > > just confirmed that with a simple test program). > > I did not know that. That helps process a bit but makes existing > situation even more of a mess then. One shouldn't call a warning > what is not a warning. You can consider it a "deprecation warning" rather than a "warning." It's not like we have extra terms to throw around that we can use for these things, and having deprecation warnings affected by -w would essentially defeat the purpose of making them warnings instead of errors in the first place. And without that, deprecating anything breaks code immediately, which for something like the standard library tends to mean that you can't deprecate anything. > My problem with existing feature set is that it has created a > whole damn zoo of compiler flags (which is bad on its own) > without addressing one of key deprecation properties - in the > very same application using one stuff may be an error and other > just an informational message. It is not something that can be > decided application-wise. As compilers go, dmd has _very_ few flags. So, we're actually pretty well off in that regard. If it were up to folks like Bearophile, we'd probably have blizzard of flags for controlling what the compiler does and doesn't warn about. Walter tends to insist on flags being truly useful. It's just a shame that he gave in and added warnings to the compiler. With regards to warnings and deprecation, we only have -wi, -w, and -d, so it's not like there are very many you have to worry about. Now, -wi should arguably be the default (which would remove a flag), and -w should definitely die IMHO, because it changes what's considered valid code - not just for the warning itself but because it affects what's considerd valid code for introspection, which can change what code gets compiled in generic code, which isn't good. And -d isn't anywhere near as useful as it used to be, since deprecation is a warning instead of an error, and it's arguably bad to make deprecation warnings go away, so arguably, -d should be removed as well (though I wouldn't expect it to be). So, ideally, we'd get rid of -wi, -w, and -d, which would fix the flag proliferation in this case, but we're probably stuck with all of them given Walter's attitude on the matter (though maybe we could talk Walter into making -w act like -wi, making it redundant). However, since -wi is really the only one that makes sense to use, you can just use -wi and not worry about the others, even if we're stuck with them being in the compiler. So, while the flag situation with regards to warnings isn't ideal, I don't think that it's all that big a problem either. - Jonathan M Davis
