July 11, 2011
Continuing the trend, more people contributed to this release than any other!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.069.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.054.zip
July 11, 2011
General annoyance:
$ dmd *.d
Warning: As of Phobos 2.054, std.ctype has been scheduled for deprecation in
January 2012. Please use std.ascii instead.
Warning: As of Phobos 2.052, std.date and std.dateparse have been scheduled for
deprecation in August 2011. Please use std.datetime instead.
Warning: As of Phobos 2.054, std.string.toupper has been scheduled for deprecation
in January 2012. Please use std.string.toUpper instead.
Warning: As of Phobos 2.054, std.string.tolower has been scheduled for deprecation
in January 2012. Please use std.string.toLower instead.
arsd/web.d(702): Error: non-final switch statement without a default is deprecated



One of these is not like the other - the last line actually tells
me where the problem is with a file and line number so fixing
it is easy.


The others just blab stuff out. IMO these scheduled for deprecation warnings are more annoying to me than just having outright errors!
July 11, 2011
Yay, my active project compiles again! With only 7 of those annoying deprecation messages... but I didn't have to insert any casts! Yay!

Almost every one of my switch statements was broken by this new release. Thankfully, it's an easy fix - go to the line it complains about and add "default: assert(0);" to shut it up.
July 11, 2011
On Monday 11 July 2011 03:41:20 Adam D. Ruppe wrote:
> General annoyance:
> $ dmd *.d
> Warning: As of Phobos 2.054, std.ctype has been scheduled for deprecation in
> January 2012. Please use std.ascii instead.
> Warning: As of Phobos 2.052, std.date and std.dateparse have been scheduled
> for deprecation in August 2011. Please use std.datetime instead.
> Warning: As of Phobos 2.054, std.string.toupper has been scheduled for
> deprecation in January 2012. Please use std.string.toUpper instead.
> Warning: As of Phobos 2.054, std.string.tolower has been scheduled for
> deprecation in January 2012. Please use std.string.toLower instead.
> arsd/web.d(702): Error: non-final switch statement without a default is
> deprecated
> 
> 
> 
> One of these is not like the other - the last line actually tells
> me where the problem is with a file and line number so fixing
> it is easy.
> 
> 
> The others just blab stuff out. IMO these scheduled for deprecation warnings are more annoying to me than just having outright errors!

The deprecation messages are pragmas. They _can't_ give a useful line number. For them to be appropriately useful, they'd have to give the file and line number where the module was imported (in the case where a module is scheduled for deprecation) or the line number where the function was used (in the case of a function is scheduled for deprecation). Pragmas can't do that.

Now, maybe the pragma messages shouldn't have be prefaced with warning (since they're _not_ a compiler warning), but there's no way for them to give file and line numbers. They're doing the best that they can.

- Jonathan M Davis
July 11, 2011
On Sunday 10 July 2011 21:04:25 Jonathan M Davis wrote:
> On Monday 11 July 2011 03:41:20 Adam D. Ruppe wrote:
> > General annoyance:
> > $ dmd *.d
> > Warning: As of Phobos 2.054, std.ctype has been scheduled for
> > deprecation in January 2012. Please use std.ascii instead.
> > Warning: As of Phobos 2.052, std.date and std.dateparse have been
> > scheduled for deprecation in August 2011. Please use std.datetime
> > instead. Warning: As of Phobos 2.054, std.string.toupper has been
> > scheduled for deprecation in January 2012. Please use
> > std.string.toUpper instead. Warning: As of Phobos 2.054,
> > std.string.tolower has been scheduled for deprecation in January 2012.
> > Please use std.string.toLower instead. arsd/web.d(702): Error:
> > non-final switch statement without a default is deprecated
> > 
> > 
> > 
> > One of these is not like the other - the last line actually tells
> > me where the problem is with a file and line number so fixing
> > it is easy.
> > 
> > 
> > The others just blab stuff out. IMO these scheduled for deprecation warnings are more annoying to me than just having outright errors!
> 
> The deprecation messages are pragmas. They _can't_ give a useful line number. For them to be appropriately useful, they'd have to give the file and line number where the module was imported (in the case where a module is scheduled for deprecation) or the line number where the function was used (in the case of a function is scheduled for deprecation). Pragmas can't do that.
> 
> Now, maybe the pragma messages shouldn't have be prefaced with warning (since they're _not_ a compiler warning), but there's no way for them to give file and line numbers. They're doing the best that they can.

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.

So, yes. The current messages leave something to be desired, but we'd need the deprecated attribute to be improved to take a message and a level of deprecation (soft vs hard) in order for the situation to be improved.

- Jonathan M Davis
July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1520.1310357559.14074.digitalmars-d-announce@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.

As in, an implementation of http://d.puremagic.com/issues/show_bug.cgi?id=5481


July 11, 2011
On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1520.1310357559.14074.digitalmars-d-announce@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.

July 11, 2011
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" <jmdavisProg@gmx.com> wrote in message news:mailman.1520.1310357559.14074.digitalmars-d-announce@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
July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1523.1310360242.14074.digitalmars-d-announce@puremagic.com...
> *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).
>

Well, that is why I asked.  Yes, what I'm proposing is not exactly what was in the bug report.

The way it seems to be done, removing a feature has three stages:
1. schedule for deprecation
2. mark as deprecated
3. remove it

The point of stage 1 seems to be to warn the programmer that some time in the future they're going to need -d to compile their code.  I'm really not convinced that this message should always be displayed, as most of the time it's useless noise.  It does however make sense to print it out when compiling with -v or generate a warning when compiled with -w (or -wi).

Then again, maybe 'scheduled for deprecation' is something that should be a lower level than warning. (If D had warning levels)  In this case it should still only print with -v or -w.


July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-announce@puremagic.com...

> 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.

Ok, would this be fixed by allowing:
deprecated module mymodule;
and the rest of it?


« First   ‹ Prev
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home