View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2011
dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
"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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
"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
Re: dmd 1.069 and 2.054 release
"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
Top | Discussion index | About this forum | D home