http://d.puremagic.com/issues/show_bug.cgi?id=9289
--- Comment #22 from Don <[email protected]> 2013-02-26 00:51:42 PST --- (In reply to comment #21) > BTW, Don, I see what you mean now, but that problem existed before making > deprecations emit warnings by default (if you used -d). The default was only > changed. It is true that there's always been a difference in is(typeof()) between when compiled with -d, and when not. However, historically that hasn't mattered so much -- it has been crazy to compile with -d. This bug report gives the -d behaviour a higher priority than the no-flags behaviour. You're assuming that when a deprecated feature appears while errors are gagged, it's because it used to compile. That assumption is false. Such code might, or might not be a use of a deprecated feature. There is no way to tell. The patch moves it from "assume it's never a deprecated feature" to "assume it's always a deprecated feature". Effectively, you're changing an accepts-invalid bug to a rejects-valid bug. It's not an improvement. Here's what I think should happen: -dXX should give a warning (not an error, not silence), whenever a deprecated feature is used when errors are gagged. In other cases, the existing behaviour (silence) should be preserved. Basically I think that with any form of -d option, deprecated features should never compile without generating a warning (even when errors are gagged). When -d is not used, it should be as if those features don't exist -- there should be no difference between something that is deprecated, vs any other sort of error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
