On Wednesday, November 07, 2012 08:03:54 monarch_dodra wrote: > On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote: > > I know there's been some long term unhappiness about the > > deprecated attribute - it's all-or-nothing approach, poor > > messages, etc. Each change in it changes the language and the > > compiler. > > I *just* had a conversation about this, but there *needs* to be a > way to to tell the compiler: "don't use deprecated stuff": If it > merely issues a warning, then you'll end up calling deprecated > code, because traits will answer positively to something that is > actually deprecated: > > For example if a range has "deprecated opIndex", and you try a > search on that range, the implementation will take the RA road... > > I had proposed a "three state -d": > -- : Deprecated stuff just can't be used > -d : You can use deprecated stuff, but you get no warning > -dw : You can use deprecated stuff, and are served with a warning
It would be better if deprecated stuff warned by default and only errored if you ask it to. The problem is that as it is now, if you mark anything is deprecated, you instantly break all code using it without warning. The only way that anyone can know if you intended for something to be deprecated and get the chance to fix their code before it breaks is if you tell them in the documenation or changelog or whatnot, which doesn't tell them where in their code they're using it, and is frequently going to be outright ignored. Certainly, from Phobos' perspective, the fact that deprecating something makes it so that it doesn't compile is a problem, because it means that as soon as we deprecate something, we break people's code (essentially without warning), and we don't want to do that. So, if we refuse to ever break people's code like that, we can't use deprecated. It would be nice to have a two-tiered approach where something is soft deprecated (and therefore warns) or is hard deprecated (and therefore gives an error), but that's been rejected in the past due to the extra complication that it adds. If we don't want to complicate the feature any further, then flags _could_ be used to control it, but then we'd probably need to make warn the default and have flags for making it an error or be ignored (or maybe even make it impossible to ignore, since it's a warning rather than an error). However, it would be bad if it were treated like a normal warning is and turned into an error with -w, because plenty of folks compile with -w, and so it would then once again become the case that deprecating anything would instantly break code without warning. As such, part of me wants to make it so that deprecated _never_ stops compilation, but you do bring up a good point that there are times that you need to (particularly where conditional compilation is concerned). - Jonathan M Davis
