On Sunday 10 July 2011 21:54:42 Jonathan M Davis wrote: > On Monday 11 July 2011 14:26:32 Daniel Murphy wrote: > > "Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message > > news:mailman.1520.1310357559.14074.digitalmars-d-annou...@puremagic.com. > > .. > > > > > Now, if deprecated were improved to take a message (and to allow for > > > soft > > > deprecation, since the messages printing here are about stuff being > > > scheduled > > > for deprecation rather than actually being deprecated yet), then > > > maybe > > > they > > > could give a useful file and line number (at least for the > > > functions), > > > since > > > then the compiler would know that a function was scheduled for > > > deprecation and > > > could warn you about using it. But since the best that we have for > > > that > > > is pragmas, that doesn't work. And actually, without that sort of > > > feature, any > > > function that isn't a template can't even have such a message - at > > > best > > > it can > > > have a note in the documentation. > > > > Would the following cover all the common use cases? (Phobos seems to be > > the biggest user of deprecated so far) > > > > deprecated("message") int a; > > deprecated("message", warn) int b; > > > > With deprecated(warn) messages only being displayed with warnings > > enabled. > > No. That's not quite right. If something is actually deprecated, -d is > required to compile using it. Being able to have a message with it - e.g. > deprecated("message") - would be very useful, because it could tell you what > you're supposed to use instead (or that nothing is replacing it if that's > the case). Error vs warning has nothing to do with it. Now, it could be > that compiling with -w would result in the message being printed even if > you compiled with -d, but that's debatable. > > In the case of something which is scheduled for deprecation, the code should > compile regardless. A message would print if that symbol were used, but > beyond that, nothing happens. That _could_ be made so that it only prints > when you compile with -w, and if it's classified as a warning, then that > would make sense, except that it shouldn't stop compilation even if > compiling with -w, so it can't really follow what warnings normally do with > -w. So, how it should function with regards to -w is debatable. > > Essentially, what's needed is the ability to give a message to the deprecate > attribute _and_ the ability to make the deprecation "soft" when it's > something which is scheduled for deprecation and not yet actually > deprecated. e.g. > > deprecated("message", hard) > deprecated("message", soft) > > or maybe > > deprecated("message", full) > deprecated("message", scheduled) > > Obviously, the message can't be required, and the default if no deprecation > type was given (soft or hard) would be hard so that you could still use > deprecated the way that we do now. But by allowing for the extra arguments, > it would be possible give a message for full/hard deprecation as well as > indicate that something is only scheduled for deprecation. > > With that implemented, it would fix the problem for functions, but I'm not > sure that it would fix the problem for modules. That would depend on how it > was implemented. As it stands, if you deprecate an entire module, you end > up doing something like > > deprecated: > > at the top of the module, which is then going to complain about each symbol > in the model individually when you use it. Ideally, you could make it > complain about the module when it's imported (and then maybe the specific > functions on top of that), and that syntax doesn't really give you that. It > just makes it complain about the symbols when you use them. But that can > work too.
*Sigh* I really need to kill the shortcut in my e-mail client for sending messages. I was about to say that an implementation of http://d.puremagic.com/issues/show_bug.cgi?id=5481 _is_ essentially what we need but that your example seems to show a lack of understanding of the feature (particularly with regards to "scheduled for deprecation" rather than full deprecation). - Jonathan M Davis
