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