dmd 1.069 and 2.054 release
Jonathan M Davis
jmdavisProg at gmx.com
Sun Jul 10 21:54:42 PDT 2011
On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1520.1310357559.14074.digitalmars-d-announce at 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.
More information about the Digitalmars-d-announce
mailing list