www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.069 and 2.054 release

reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jul 10 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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!
Jul 10 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 10 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jonathan M Davis wrote:
 The deprecation messages are pragmas. They _can't_ give a useful
 line number.

My "solution" is to replace the pragma with a static assert(0) so the compiler gives an error and call trace. /home/me/d/dmd2/linux/bin32/../../src/phobos/std/string.d(885): Error: static assert (0) is false arsd/web.d(575): instantiated from here: tolower!(string) [snip] static assert(0) is actually my go-to replacement when things start to go belly up, especially with templates. The list of instantiated from here lines is a huge help when figuring it all out. Anyway, the pragma is meant to be informative and the assert is an error. But, there's an easy "fix" for that too. In std.string there's a softDeprec template. I think this is new and it's private to std.string, but it's great because we can add: version(scheduled_for_deprecation_is_an_error) static assert(0); Thus: === private template softDeprec(string vers, string date, string oldFunc, string newFunc) { version(scheduled_for_deprecation_is_an_error) static assert(0); enum softDeprec = Format!("Warning: As of Phobos %s, std.string.%s has been scheduled " ~ === And then you get a full error with details upon request. (btw I keep putting fix and such in quotes because this is a filthy hack!)
Jul 11 2011
parent Adam Ruppe <destructionator gmail.com> writes:
Jonathan M Davis:
 If it gives you  stack trace though, I guess that it would help,
 though it would certainly be ugly.

It's not too ugly at all, since it's a template stack trace - so in a lot of cases, it isn't a very long list. Regardless though, something is better than nothing.
 Fortunately, in the case of something like tolower, _every_
 function called

Indeed, though another one was repeat() with replicate(), which isn't as simple without the compiler's help. While a proper warning is surely better than a filthy hack, if it's not coming, adding a versioned static assert is a low cost alternative we can do immediately.
Jul 11 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 10 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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
Jul 10 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 10 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Jul 10 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j gmail.com> said:

 To paraphrase your description, there's something that's about to break in
 your code, but it's not broken yet, so if you drop -w (or switch to -wi),
 you can still build it. If we're taking the approach that warnings break
 code when -w is used, I see scheduled deprecations falling into a very
 similar category.

To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword. Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d. I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 11 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-07-11 19:56:28 -0400, "Jonathan M Davis" <jmdavisProg gmx.com> said:

 The problem with not having a message is that people aren't likely to look at
 the documentation unless they aren't all that familiar with the function, so
 people will continue to happily use the function up to the point that it's
 actually deprecated, and then they'll be surpised when their code breaks
 (since suddenly needing -d for your code to compile _is_ breaking your code).
 Walter in particular doesn't like the idea of people suddenly having to go and
 change their build scripts to use -d or immediately fix their code without any
 warning, which is why we don't deprecate immediately.

Very true. I take this as an indication that the current implementation of the `deprecated` keyword is too strict by default. If it's bad that using a deprecated function breaks the code by default, then make using a deprecated function non-fatal unless the user asks for it to be fatal. To me, something scheduled for deprecation means that you know it'll be deprecated eventually, but that for now it's still okay using it. For instance, std.xml could be scheduled for deprecation, once we have a replacement we can deprecate it and nag people about using the new one. If you nag people immediately, then it's almost as good as deprecated already. That said, there's also the problem that the implementation of the "scheduled for deprecation" messages isn't very good. It'll work for modules, it'll work for template functions, but you don't know who imported the module or called the function. Moreover, calling a deprecated function from within a deprecated function yields no error; calling a scheduled-for-deprecation function from a scheduled-for-deprecation one or even a deprecated one will show an annoying message. Does that makes sense? Instead of working on fragile workarounds, better fix the problem, which is that `deprecated` is too strict by default. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 11 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-07-12 16:52:10 -0400, Leandro Lucarella <luca llucax.com.ar> said:

 This is what deprecated is for! Removing stuff breaks code, not
 deprecating stuff! Deprecated really is "scheduled for removal", so
 "scheduled for deprecation" is "scheduled for scheduled for removal", it
 makes no sense. Fix the compiler!

Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet. Now, I think the argument for scheduling things for deprecation is just an extreme of that: deprecating things is a nuisance because it breaks code, so we'll schedule them to be deprecated later. But then we add a warning for those things scheduled for deprecation because we don't want people to use them, and "scheduled for deprecation" has just become a synonym for "deprecated but not yet breaking your code". Fixing deprecated to not break code by default is a better option, I think. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 12 2011
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Michel Fortin, el 12 de julio a las 18:03 me escribiste:
 On 2011-07-12 16:52:10 -0400, Leandro Lucarella <luca llucax.com.ar> said:
This is what deprecated is for! Removing stuff breaks code, not
deprecating stuff! Deprecated really is "scheduled for removal", so
"scheduled for deprecation" is "scheduled for scheduled for removal", it
makes no sense. Fix the compiler!

Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet.

What's the point of scheduling something for removal when you don't have an alternative? I really can't see the point. If you just plan to do an alternative but you don't want to bother anyone, just don't mark it as deprecated. If you do want to tell people "hey, better not to use this", then mark it as deprecated. If you have a replacement you can't even schedule anything, and if you can, you can deprecate it too.
 Now, I think the argument for scheduling things for deprecation is
 just an extreme of that: deprecating things is a nuisance because it
 breaks code, so we'll schedule them to be deprecated later. But then
 we add a warning for those things scheduled for deprecation because
 we don't want people to use them, and "scheduled for deprecation"
 has just become a synonym for "deprecated but not yet breaking your
 code". Fixing deprecated to not break code by default is a better
 option, I think.

Agreed, changing the default in my patch is a one-line change. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- hypocrite opportunist don't infect me with your poison
Jul 12 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jul 10 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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.
Jul 10 2011
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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?
Jul 10 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1522.1310360091.14074.digitalmars-d-announce puremagic.com...
 On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
 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.

Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
Jul 11 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 15:31:11 Daniel Murphy wrote:
 "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.

A message needs to be printed in stage 1. Whether it should always be printed is debatable. But without the message, unless the programmer is re-reading the documentation, they won't see that something has been scheduled for deprecation. On some level, the programmer _should_ be bugged about it, because they need to change their code, but on the other hand, it's scheduled for deprecation rather than deprecated precisely so that the programmer has time to change their code before the item in question is deprecated, so always bugging about it doesn't really make sense either. So, making it so that it only prints with -v or -w is probably fine. But regardless, the whole point is to alert the programmer so that they have the chance to change their code before they need to start compiling with -d. So, the message needs to be there, but I'm not sure that I really care that much about whether it always prints or not. Having it always print with -w, -wi, or -v but otherwise not print is probably fine.
 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?

I think that it's all been covered. Stage 1 needs an appropriate message and a way to put that message on specific symbols (and possibly modules). Stage 2 currently works as-is but would be better with a message. And, of course, stage 3 works quite well without any features at all. So, overall I think that that covers it. The exact details of how it interacts with compiler flags is up for some debate, and I'm not sure that I care a whole lot about how that's dealt with except that the messages for stage 1 need to be seen, so they need to be displayed when a reasonable set of compiler flags is used. Otherwise, the deprecation will come to surprise to people and cause them even more problems. - Jonathan M Davis
Jul 10 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1524.1310363419.14074.digitalmars-d-announce puremagic.com...
[snip]
Yeah ok, I think we're more or less on the same page now.

Looking at the implementation of deprecated, I think in order to support 
messages it's going to need to become a pragma rather than a storage class. 
(at least internally)

Maybe we should deprecate deprecated? :) 
Jul 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 17:29:07 Daniel Murphy wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1524.1310363419.14074.digitalmars-d-announce puremagic.com...
 [snip]
 Yeah ok, I think we're more or less on the same page now.
 
 Looking at the implementation of deprecated, I think in order to support
 messages it's going to need to become a pragma rather than a storage class.
 (at least internally)
 
 Maybe we should deprecate deprecated? :)

LOL. Well, from the programmer's point of view, I don't think that it really matters how deprecated is implemented internally. It just needs to work. However, regardless of its being able to take a message or type of deprecation, the current behavior of deprecated needs to stay intact. Its new abilities need to be in addition to how it currently works rather than replacing them. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-07-11 05:07, Walter Bright wrote:
 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

That was no short list, impressive. -- /Jacob Carlborg
Jul 11 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 10:01:26 Jacob Carlborg wrote:
 On 2011-07-11 05:07, Walter Bright wrote:
 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

That was no short list, impressive.

It definitely is impressive. Probably the longest list ever. I would point out however, that this line shouldn't be in the changelog: * Add warning about calling pure nothrow functions and ignoring the result That change was reverted after it was discovered that it caused too many problems. - Jonathan M Davis
Jul 11 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 01:11:09 Jonathan M Davis wrote:
 On Monday 11 July 2011 10:01:26 Jacob Carlborg wrote:
 On 2011-07-11 05:07, Walter Bright wrote:
 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

That was no short list, impressive.

It definitely is impressive. Probably the longest list ever. I would point out however, that this line shouldn't be in the changelog: * Add warning about calling pure nothrow functions and ignoring the result That change was reverted after it was discovered that it caused too many problems.

Oh, and this line should be removed too: * Added inference for purity and safety It's basically listed twice, since there's also this line (which is more accurate): * Automatic inference for safe, pure, nothrow - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent reply Stephan <spam extrawurst.org> writes:
On 11.07.2011 05:07, Walter Bright wrote:
 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

Nice release list. "Added std.array.uninitializedArray and std.array.minimallyInitializedArray" The online documentation of std.array doesn't seem to be updated. The above isn't present there.
Jul 11 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 11:00:15 Stephan wrote:
 On 11.07.2011 05:07, Walter Bright wrote:
 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

Nice release list. "Added std.array.uninitializedArray and std.array.minimallyInitializedArray" The online documentation of std.array doesn't seem to be updated. The above isn't present there.

Give it some time. A new release and the updating of the online documentation aren't automatically linked. Walter is the one putting up the new release, I believe that Andrei is the one who has to update the site. Walter put up the release about 6 hours ago. There's a decent chance that Andrei isn't even aware that the release has been done yet. The site will be probably be updated within the next 24 hours. But regardless, the fact remains that the site update and the release itself aren't done by the same person, so the site update is likely to be somewhat delayed. The docs in the zip file should be properly up-to-date. - Jonathan M Davis
Jul 11 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/11/11 4:11 AM, Jonathan M Davis wrote:
 On Monday 11 July 2011 11:00:15 Stephan wrote:
 On 11.07.2011 05:07, Walter Bright wrote:
 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

Nice release list. "Added std.array.uninitializedArray and std.array.minimallyInitializedArray" The online documentation of std.array doesn't seem to be updated. The above isn't present there.

Give it some time. A new release and the updating of the online documentation aren't automatically linked. Walter is the one putting up the new release, I believe that Andrei is the one who has to update the site. Walter put up the release about 6 hours ago. There's a decent chance that Andrei isn't even aware that the release has been done yet. The site will be probably be updated within the next 24 hours. But regardless, the fact remains that the site update and the release itself aren't done by the same person, so the site update is likely to be somewhat delayed. The docs in the zip file should be properly up-to-date. - Jonathan M Davis

I tried to rebuild the site, the 2.054 tag is not yet present in phobos. Andrei
Jul 11 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2011 8:31 AM, Andrej Mitrovic wrote:
 Walter, could you please add these to the changelog:

Done.
Jul 12 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Walter, could you please add these to the changelog:

http://d.puremagic.com/issues/show_bug.cgi?id=6026
http://d.puremagic.com/issues/show_bug.cgi?id=5869
http://d.puremagic.com/issues/show_bug.cgi?id=5836
http://d.puremagic.com/issues/show_bug.cgi?id=5598
http://d.puremagic.com/issues/show_bug.cgi?id=5458
http://d.puremagic.com/issues/show_bug.cgi?id=5059
http://d.puremagic.com/issues/show_bug.cgi?id=6101

These were all fixed since 2.043, but I didn't touch the changelog so
they were left out.

Great work everybody on this release!
Jul 11 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Also this is a worksforme fix, not a library fix and it doesn't belong
in the changelog:

Bugzilla 3564: Rdmd failing to link external C libraries

Unless someone changed how rdmd does its argument passing.
Jul 11 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Thanks!
Jul 12 2011
prev sibling next sibling parent reply Stephan <spam extrawurst.org> writes:
On 11.07.2011 05:07, Walter Bright wrote:
 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

I like this one: "Added -property switch" But since phobos does not even build with it (in win32) it is pretty much useless: phobos\std\file.d(228): Error: not a property GetLastError: version(Windows) this(in char[] name, uint errno = GetLastError, string file = __FILE__, size_t line = __LINE__){...}
Jul 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2011 2:21 AM, Stephan wrote:
 But since phobos does not even build with it (in win32) it is pretty much
useless:

Right, that's why it was not made the default. It is there for people to experiment with.
Jul 11 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-07-11 05:49:14 -0400, Walter Bright <newshound2 digitalmars.com> said:

 On 7/11/2011 2:21 AM, Stephan wrote:
 But since phobos does not even build with it (in win32) it is pretty 
 much useless:

Right, that's why it was not made the default. It is there for people to experiment with.

And also so that we can work on that problem. My work in progress: Phobos: <https://github.com/michelf/phobos/compare/master...%40property> Druntime: <https://github.com/michelf/druntime/compare/master...%40property> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 11 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin

 And also so that we can work on that problem. My work in progress:

Very good. Bye, bearophile
Jul 11 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 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

Great release! I noticed that auto ref function parameters are now implemented, but only for template functions. Is there a reason for this limitation? Example: Works: void foo()(auto ref int num) { num++; } Doesn't: void foo(auto ref int num) { num++; }
Jul 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2011 7:04 AM, dsimcha wrote:
 Great release!  I noticed that auto ref function parameters are now
implemented,
 but only for template functions.  Is there a reason for this limitation? 
Example:

 Works:

 void foo()(auto ref int num) {
      num++;
 }

 Doesn't:

 void foo(auto ref int num) {
      num++;
 }

auto ref changes the code generated for the function body, so it must be a template.
Jul 11 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 7/11/2011 7:04 AM, dsimcha wrote:
 Great release!  I noticed that auto ref function parameters are now
implemented,
 but only for template functions.  Is there a reason for this limitation? 
Example:

 Works:

 void foo()(auto ref int num) {
      num++;
 }

 Doesn't:

 void foo(auto ref int num) {
      num++;
 }


So are there multiple instantiations depending on rvalue vs. not rvalue?
Jul 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2011 10:02 AM, dsimcha wrote:
 So are there multiple instantiations depending on rvalue vs. not rvalue?

Yes, it has to be that way. It's the difference between passing T* and T.
Jul 11 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 7/11/2011 10:02 AM, dsimcha wrote:
 So are there multiple instantiations depending on rvalue vs. not rvalue?


Couldn't you just make the calling convention for auto ref functions be to always pass a T* and create a hidden temporary at the call site if passing an rvalue?
Jul 11 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/11/2011 12:16 PM, dsimcha wrote:
 Couldn't you just make the calling convention for auto ref functions be to
always
 pass a T* and create a hidden temporary at the call site if passing an rvalue?

That can produce a lot of hidden overhead, pretty much wrecking the advantages of pass by value.
Jul 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 11 July 2011 13:16:59 Adam D. Ruppe wrote:
 Jonathan M Davis wrote:
 The deprecation messages are pragmas. They _can't_ give a useful
 line number.

My "solution" is to replace the pragma with a static assert(0) so the compiler gives an error and call trace. /home/me/d/dmd2/linux/bin32/../../src/phobos/std/string.d(885): Error: static assert (0) is false arsd/web.d(575): instantiated from here: tolower!(string) [snip] static assert(0) is actually my go-to replacement when things start to go belly up, especially with templates. The list of instantiated from here lines is a huge help when figuring it all out. Anyway, the pragma is meant to be informative and the assert is an error. But, there's an easy "fix" for that too. In std.string there's a softDeprec template. I think this is new and it's private to std.string, but it's great because we can add: version(scheduled_for_deprecation_is_an_error) static assert(0); Thus: === private template softDeprec(string vers, string date, string oldFunc, string newFunc) { version(scheduled_for_deprecation_is_an_error) static assert(0); enum softDeprec = Format!("Warning: As of Phobos %s, std.string.%s has been scheduled " ~ === And then you get a full error with details upon request. (btw I keep putting fix and such in quotes because this is a filthy hack!)

I created softDeprec to make it easier to make the pragma messages (and to ensure that they're consistent). I believe that both std.string and std.file have one, and the idea is that once they're no longer needed, they'll go away. The version idea is an interesting one, but I'm not sure if it helps much. The error message would give the file and line number of the pragma, not where the function was used. And what you really need to know is where the function was used so that you can track it down and replace it. If it gives you stack trace though, I guess that it would help, though it would certainly be ugly. Fortunately, in the case of something like tolower, _every_ function called tolower is scheduled for deprecation (unless you created one in your own code), so simply searching for it in your code will locate the ones that need to be replaced, but still, the current situation is less than ideal. What we really need is something like what I was discussing with Daniel - an improvement to the deprecated attribute so that it can be used in this kind of situation. Then it can become an actual compiler warning, though it wouldn't exactly be a normal one, since a function which has only been scheduled for deprecation should never cause the compilation to fail because it's used. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Btw. Walter, why not distribute HTOD with DMD? Also implib and rcc
from your basic utilities package are very useful to have in D. :-)
Jul 11 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 09:34, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1522.1310360091.14074.digitalmars-d-announce puremagic.com...
 
 On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
 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.

Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation. - Jonathan M Davis
Jul 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1536.1310408114.14074.digitalmars-d-announce puremagic.com...
 On 2011-07-11 09:34, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1522.1310360091.14074.digitalmars-d-announce puremagic.com...

 On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
 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.

Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation.

Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.) To be clear, if we did have some "deprecated(scheduled)" feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that "scheduled for deprication" doesn't essentially amount to a warning.
Jul 11 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 13:09, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1536.1310408114.14074.digitalmars-d-announce puremagic.com...
 
 On 2011-07-11 09:34, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1522.1310360091.14074.digitalmars-d-announce puremagic.com.
 ..
 
 On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
 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.

Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation.

Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.) To be clear, if we did have some "deprecated(scheduled)" feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that "scheduled for deprication" doesn't essentially amount to a warning.

Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage. So, I don't know what the best way to handle to scheduled for deprecation messages is, but they really shouldn't cause code to not compile or force you to use a specific flag to make your code compile. Otherwise, we might as well just fully deprecate them from the get-go. The simplest way is to just always print the messages until you fix your code, but that could be annoying. So, I don't know. But scheduled for deprecation messages must not break code. - Jonathan M Davis
Jul 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1539.1310416341.14074.digitalmars-d-announce puremagic.com...
 On 2011-07-11 13:09, Nick Sabalausky wrote:
 Not that I feel strongly about it, but just like "scheduled for
 deprication", actual warnings are things that *are* valid code, too. Ie,
 they're just messages, too. The whole point of a "warnings as errors"
 setting is that some people want that extra help to ensure their code is
 perfectly pristine. (Although, personally, I've never seen particularly
 strong reason for "warnings as errors" settings anyway.)

 To be clear, if we did have some "deprecated(scheduled)" feature and it 
 was
 non-fatal even with -w, I wouldn't personally have a huge problem with it
 (I never use -w anyway, just -wi). I just don't think it's so clear-cut
 that "scheduled for deprication" doesn't essentially amount to a warning.

Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage.

If someone doesn't want warning conditions to break their code, they should be using -wi, not -w.
Jul 11 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 13:50, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1539.1310416341.14074.digitalmars-d-announce puremagic.com...
 
 On 2011-07-11 13:09, Nick Sabalausky wrote:
 Not that I feel strongly about it, but just like "scheduled for
 deprication", actual warnings are things that *are* valid code, too. Ie,
 they're just messages, too. The whole point of a "warnings as errors"
 setting is that some people want that extra help to ensure their code is
 perfectly pristine. (Although, personally, I've never seen particularly
 strong reason for "warnings as errors" settings anyway.)
 
 To be clear, if we did have some "deprecated(scheduled)" feature and it
 was
 non-fatal even with -w, I wouldn't personally have a huge problem with
 it (I never use -w anyway, just -wi). I just don't think it's so
 clear-cut that "scheduled for deprication" doesn't essentially amount
 to a warning.

Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage.

If someone doesn't want warning conditions to break their code, they should be using -wi, not -w.

Yes. But the problem is that the "scheduled for deprecation" messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile. Bottom line. Marking something as "scheduled for deprecation" should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately. - Jonathan M Davis
Jul 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1542.1310418661.14074.digitalmars-d-announce puremagic.com...
 Yes. But the problem is that the "scheduled for deprecation" messages are 
 not
 supposed to _ever_ break code. And since warnings aren't normally added 
 very
 often, compiling with -w shouldn't cause your code to suddenly break. 
 Granted,
 dmd is still unstable enough that such changes do occur, but once it's 
 fully
 stable, it wouldn't happen very often. But anyone can schedule something 
 for
 deprecation in any library, and the whole point of _scheduling_ the
 deprecation instead of just deprecating it is to avoid breaking code. So, 
 it's
 unacceptable for scheduling something for deprecation to be an error 
 with -w.
 It's informational only. Warnings are _not_ only informational. They're
 telling you that there's actually something wrong with your code.

Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning. And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives. I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).
 It's just
 not wrong enough to be against the language spec and therefore always be 
 an
 error. Scheduling something for deprecation is indicating that the symbol 
 in
 question will be deprecated in the future and that you should change it 
 before
 that happens. Your code is still fine, and it should still compile.

 Bottom line. Marking something as "scheduled for deprecation" should 
 _never_
 break code no matter what flags you use to compile your code. Otherwise,
 there's no point to it, and we'd just be deprecating stuff immediately.

 - Jonathan M Davis 

Jul 11 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--001636c924e88831d704a7d1d6b9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On 2011-07-11 13:50, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1539.1310416341.14074.digitalmars-d-announce puremagic.com.

 On 2011-07-11 13:09, Nick Sabalausky wrote:
 Not that I feel strongly about it, but just like "scheduled for
 deprication", actual warnings are things that *are* valid code, too.



 they're just messages, too. The whole point of a "warnings as errors"
 setting is that some people want that extra help to ensure their code



 perfectly pristine. (Although, personally, I've never seen



 strong reason for "warnings as errors" settings anyway.)

 To be clear, if we did have some "deprecated(scheduled)" feature and



 was
 non-fatal even with -w, I wouldn't personally have a huge problem with
 it (I never use -w anyway, just -wi). I just don't think it's so
 clear-cut that "scheduled for deprication" doesn't essentially amount
 to a warning.

Hmm. The main problem with making the scheduled for deprecation


 being
 treated as errors with -w is that if you build with -w (as a lot of
 people do), it breaks your code. And the point of the message is to


 you that your code is _going_ to break and to _avoid_ causing immediate
 breakage.

If someone doesn't want warning conditions to break their code, they

 be using -wi, not -w.

Yes. But the problem is that the "scheduled for deprecation" messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile. Bottom line. Marking something as "scheduled for deprecation" should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately.

I would argue that when you compile with -w (and explicitly -w, not -wi), you're explicitly asking the compiler to break your code for warnings, and I believe that should include code scheduled for deprecation. By specifying -w, you're explicitly asking the compiler to check your code more strictly, and I see more aggressive deprecation as an acceptable part of that. To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category. And no, this change doesn't obsolete code deprecation, it simply extends the higher standards that -w holds you to into the library space. If you don't want "scheduled for deprecation" to break your code, use -wi. You'll get all the same noise you got before, just without the breakage. --001636c924e88831d704a7d1d6b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davi= s <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg = gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On 2011-07-11 13:50, Nick Sabalausky wrot= e:<br> &gt; &quot;Jonathan M Davis&quot; &lt;<a href=3D"mailto:jmdavisProg gmx.com= ">jmdavisProg gmx.com</a>&gt; wrote in message<br> &gt; news:mailman.1539.1310416341.14074.digitalmars-d-announce puremagic.co= m...<br> &gt;<br> &gt; &gt; On 2011-07-11 13:09, Nick Sabalausky wrote:<br> &gt; &gt;&gt; Not that I feel strongly about it, but just like &quot;schedu= led for<br> &gt; &gt;&gt; deprication&quot;, actual warnings are things that *are* vali= d code, too. Ie,<br> &gt; &gt;&gt; they&#39;re just messages, too. The whole point of a &quot;wa= rnings as errors&quot;<br> &gt; &gt;&gt; setting is that some people want that extra help to ensure th= eir code is<br> &gt; &gt;&gt; perfectly pristine. (Although, personally, I&#39;ve never see= n particularly<br> &gt; &gt;&gt; strong reason for &quot;warnings as errors&quot; settings any= way.)<br> &gt; &gt;&gt;<br> &gt; &gt;&gt; To be clear, if we did have some &quot;deprecated(scheduled)&= quot; feature and it<br> &gt; &gt;&gt; was<br> &gt; &gt;&gt; non-fatal even with -w, I wouldn&#39;t personally have a huge= problem with<br> &gt; &gt;&gt; it (I never use -w anyway, just -wi). I just don&#39;t think = it&#39;s so<br> &gt; &gt;&gt; clear-cut that &quot;scheduled for deprication&quot; doesn&#3= 9;t essentially amount<br> &gt; &gt;&gt; to a warning.<br> &gt; &gt;<br> &gt; &gt; Hmm. The main problem with making the scheduled for deprecation m= essages<br> &gt; &gt; being<br> &gt; &gt; treated as errors with -w is that if you build with -w (as a lot = of<br> &gt; &gt; people do), it breaks your code. And the point of the message is = to warn<br> &gt; &gt; you that your code is _going_ to break and to _avoid_ causing imm= ediate<br> &gt; &gt; breakage.<br> &gt;<br> &gt; If someone doesn&#39;t want warning conditions to break their code, th= ey should<br> &gt; be using -wi, not -w.<br> <br> </div></div>Yes. But the problem is that the &quot;scheduled for deprecatio= n&quot; messages are not<br> supposed to _ever_ break code. And since warnings aren&#39;t normally added= very<br> often, compiling with -w shouldn&#39;t cause your code to suddenly break. G= ranted,<br> dmd is still unstable enough that such changes do occur, but once it&#39;s = fully<br> stable, it wouldn&#39;t happen very often. But anyone can schedule somethin= g for<br> deprecation in any library, and the whole point of _scheduling_ the<br> deprecation instead of just deprecating it is to avoid breaking code. So, i= t&#39;s<br> unacceptable for scheduling something for deprecation to be an error with -= w.<br> It&#39;s informational only. Warnings are _not_ only informational. They&#3= 9;re<br> telling you that there&#39;s actually something wrong with your code. It&#3= 9;s just<br> not wrong enough to be against the language spec and therefore always be an= <br> error. Scheduling something for deprecation is indicating that the symbol i= n<br> question will be deprecated in the future and that you should change it bef= ore<br> that happens. Your code is still fine, and it should still compile.<br> <br> Bottom line. Marking something as &quot;scheduled for deprecation&quot; sho= uld _never_<br> break code no matter what flags you use to compile your code. Otherwise,<br=

ely.</blockquote><div><br></div><div>I would argue that when you compile wi= th -w (and explicitly -w, not -wi), you&#39;re explicitly asking the compil= er to break your code for warnings, and I believe that should include code = scheduled for deprecation. By specifying -w, you&#39;re explicitly asking t= he compiler to check your code more strictly, and I see more aggressive dep= recation as an acceptable part of that.</div> <div><br></div><div>To paraphrase your description, there&#39;s something t= hat&#39;s about to break in your code, but it&#39;s not broken yet, so if y= ou drop -w (or switch to -wi), you can still build it. If we&#39;re taking = the approach that warnings break code when -w is used, I see scheduled depr= ecations falling into a very similar category.</div> <div><br></div><div>And no, this change doesn&#39;t obsolete code deprecati= on, it simply extends the higher standards that -w holds you to into the li= brary space. If you don&#39;t want &quot;scheduled for deprecation&quot; to= break your code, use -wi. You&#39;ll get all the same noise you got before= , just without the breakage.</div> </div> --001636c924e88831d704a7d1d6b9--
Jul 11 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 14:32, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1542.1310418661.14074.digitalmars-d-announce puremagic.com...
 
 Yes. But the problem is that the "scheduled for deprecation" messages are
 not
 supposed to _ever_ break code. And since warnings aren't normally added
 very
 often, compiling with -w shouldn't cause your code to suddenly break.
 Granted,
 dmd is still unstable enough that such changes do occur, but once it's
 fully
 stable, it wouldn't happen very often. But anyone can schedule something
 for
 deprecation in any library, and the whole point of _scheduling_ the
 deprecation instead of just deprecating it is to avoid breaking code. So,
 it's
 unacceptable for scheduling something for deprecation to be an error
 with -w.
 It's informational only. Warnings are _not_ only informational. They're
 telling you that there's actually something wrong with your code.

Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning. And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives. I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).

Honestly, I would consider it bad practice to leave warnings in code. Leaving them in as you're messing with code is fine, because they're not immediately fatal, but they _are_ problems. If they weren't, then they shouldn't have been warnings in the first place. But I tend to mostly agree with Walter that something should either be an error or not. Warnings are for things which are definitely wrong but not illegal in the language. Certainly, that's how dmd treats them. I know that other compilers love to complain about other stuff that doesn't really matter but _could_ be a bug, but once you do that, people start letting warnings sit there, and _real_ problems get buried in the mess. So, obviously, we have a very different view of warnings. But regardless, it's going to cause problems if scheduling something for deprecation causes code to break. The whole point is to inform programmers that they're going to need to change their code soon and to avoid immediate code breakage. Treating "scheduled for deprecation" as a warning doesn't do that. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 14:32, Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1542.1310418661.14074.digitalmars-d-announce puremagic.com...
 
 Yes. But the problem is that the "scheduled for deprecation" messages are
 not
 supposed to _ever_ break code. And since warnings aren't normally added
 very
 often, compiling with -w shouldn't cause your code to suddenly break.
 Granted,
 dmd is still unstable enough that such changes do occur, but once it's
 fully
 stable, it wouldn't happen very often. But anyone can schedule something
 for
 deprecation in any library, and the whole point of _scheduling_ the
 deprecation instead of just deprecating it is to avoid breaking code. So,
 it's
 unacceptable for scheduling something for deprecation to be an error
 with -w.
 It's informational only. Warnings are _not_ only informational. They're
 telling you that there's actually something wrong with your code.

Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning. And "scheduled for deprecation" is literally saying "your code *will* be wrong, and you *do* need to address it by X deadline". That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives. I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of "warnings as errors" in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of "warnings as errors" is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability).

Honestly, I would consider it bad practice to leave warnings in code. Leaving them in as you're messing with code is fine, because they're not immediately fatal, but they _are_ problems. If they weren't, then they shouldn't have been warnings in the first place. But I tend to mostly agree with Walter that something should either be an error or not. Warnings are for things which are definitely wrong but not illegal in the language. Certainly, that's how dmd treats them. I know that other compilers love to complain about other stuff that doesn't really matter but _could_ be a bug, but once you do that, people start letting warnings sit there, and _real_ problems get buried in the mess. So, obviously, we have a very different view of warnings. But regardless, it's going to cause problems if scheduling something for deprecation causes code to break. The whole point is to inform programmers that they're going to need to change their code soon and to avoid immediate code breakage. Treating "scheduled for deprecation" as a warning doesn't do that. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-11 16:09, Michel Fortin wrote:
 On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j gmail.com> said:
 To paraphrase your description, there's something that's about to break
 in your code, but it's not broken yet, so if you drop -w (or switch to
 -wi), you can still build it. If we're taking the approach that warnings
 break code when -w is used, I see scheduled deprecations falling into a
 very similar category.

To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword. Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d. I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view.

Well, we've been doing it with pragmas for a while (which was Andrei's idea IIRC). We just haven't been very organized about it, and I've been trying to better organize what we're doing with deprecation. And since it only works with full modules or with templated functions (since otherwise the pragma would bug everyone rather than just those using the symbol in question), it can't be used everywhere anyway. The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately. And just putting it in the documentation really isn't much better than deprecating it immediately, because the very people who most need to see the message are the least likely to read the documentation. Now, if most people don't like the idea of messages about stuff being scheduled for deprecation being printed, then we'll likely stop having them. But it kind of defeats the purpose of scheduling it for deprecation rather than immediately deprecating it if we do that. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
 Despite the confusing non-standard descriptions in --help, -w is the "Treat
 warnings as errors" setting, so it *should* stop compilation - that's the
 whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation

What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <mazzi> gmail is down? <Luca> waiting for mail.google.com.... <mazzi> ya vendĂ­ todas mis acciones de google en los mercados asiaticos <Luca> se viene la ecatombe <mazzi> mal <mazzi> es como que te corten el porno en una tarde al pedo en tu casa
Jul 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
 Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
 Despite the confusing non-standard descriptions in --help, -w is the
 "Treat warnings as errors" setting, so it *should* stop compilation
 - that's the whole point of -w. The proper "Turn warnings on"
 setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation

What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.

The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol. So, in the "scheduled for deprecation" stage, programmers are warned that a symbol will be deprecated in the near future, but the symbol hasn't been deprecated yet, so no code is broken, and no build scripts need to b changed. Programmers then have time to rework their code to no longer use the soon-to- be deprecated symbol without having their code break or having to change their build scripts. If a programmer has not done anything about the symbol before it's actually deprecated, then they will have to change their code or change their bulid scripts to use -d when the symbol is actually deprecated, but because there was the "scheduled for deprecation" phase, the programmer at least had fair warning about the impending code breakage and could have avoided it had they wanted to. What it comes down to is that we don't want to suddenly break anyone's code. If breaking changes need to be made, we want to provide a smooth path, giving people time to rework their code rather than suddenly breaking their code. Needing to rework your code can be annoying enough without your code suddenly breaking due to a library update. - Jonathan M Davis
Jul 11 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
In general good work!

But again phobos makes a simple std.string function unCTFEable.
Now I have to use an ugly hack to achieve something as simple as toUpper:

mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );
Jul 12 2011
next sibling parent reply Stephan <spam extrawurst.org> writes:
On 12.07.2011 15:10, Trass3r wrote:
 In general good work!

 But again phobos makes a simple std.string function unCTFEable.
 Now I have to use an ugly hack to achieve something as simple as toUpper:

 mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );

Damn i found that too and wanted to mention it in the dmd-beta list b4 release. But the workaround is simple. At least this one was fixed: http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html Cause that was making cl4d with all its string mixins pretty much unbuildable at all.
Jul 12 2011
parent Stephan <spam extrawurst.org> writes:
On 12.07.2011 17:07, Trass3r wrote:
 Now I have to use an ugly hack to achieve something as simple as
 toUpper:

 mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );

Damn i found that too and wanted to mention it in the dmd-beta list b4 release. But the workaround is simple. At least this one was fixed: http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html Cause that was making cl4d with all its string mixins pretty much unbuildable at all.

Yeah I've done some crazy shit in the cl4d code :D But in the end that was just another workaround cause template mixins couldn't mixin constructors. Good news: this seems to have been fixed. Bad news: there still is another problem. I asked about it in D.learn. btw, that problem you reported, where did it occur in cl4d?

It occured for the mixin method to generate the different exception classes. Specifically the toCamelCase method was not working there.
Jul 13 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 Now I have to use an ugly hack to achieve something as simple as  
 toUpper:

 mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );

Damn i found that too and wanted to mention it in the dmd-beta list b4 release. But the workaround is simple. At least this one was fixed: http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html Cause that was making cl4d with all its string mixins pretty much unbuildable at all.

Yeah I've done some crazy shit in the cl4d code :D But in the end that was just another workaround cause template mixins couldn't mixin constructors. Good news: this seems to have been fixed. Bad news: there still is another problem. I asked about it in D.learn. btw, that problem you reported, where did it occur in cl4d?
Jul 12 2011
prev sibling parent Trass3r <un known.com> writes:
 It occured for the mixin method to generate the different exception  
 classes. Specifically the toCamelCase method was not working there.

Ok. Do you have any idea how to solve the problem I described in D.learn? ("template instance cannot use local.....")
Jul 13 2011
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el 11 de julio a las 22:21 me escribiste:
 On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
 Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
 Despite the confusing non-standard descriptions in --help, -w is the
 "Treat warnings as errors" setting, so it *should* stop compilation
 - that's the whole point of -w. The proper "Turn warnings on"
 setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation

What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.

The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.

If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- No tengo alas, como un planeador. No tengo luces, como un plato volador. Perdi mi rumbo soy un auto chocador.
Jul 12 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-12 10:07, Leandro Lucarella wrote:
 Jonathan M Davis, el 11 de julio a las 22:21 me escribiste:
 On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
 Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
 Despite the confusing non-standard descriptions in --help, -w is
 the "Treat warnings as errors" setting, so it *should* stop
 compilation - that's the whole point of -w. The proper "Turn
 warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation

What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.

The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.

If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.

Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D. When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process. 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes. 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts. 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over. The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that. - Jonathan M Davis
Jul 12 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jonathan M Davis wrote:
 Deprecating something is still going to break code

Breaking with deprecated is an entirely different kind of breakage than removing something. deprecated means simply "please don't use this specific thing". You can tell it "shut up I know better than you" and be on your way. It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too. Here's my preference list for changes: Top preference: don't change stuff. Next: use the deprecated attribute Next: versioned scheduled to be deprecated messages. I don't like being spammed every time I compile. Next: scheduled to be deprecated messages as they are now Last: removing it entirely. (this should be very, very rare especially if we want to be called stable. Nothing has pissed me off more with the last few releases than Phobos losing functionality.)
Jul 12 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Jonathan M Davis wrote:
 The current plan is that _everything_ which gets deprecated will
 be removed.

What's the reason for removing things? Surely it's not disk space! Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence. Painful changes though, are, well, painful.
 1. Renaming stuff to follow Phobos' naming conventions.

These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name). Do it fast, feel the brief pain, and move on.
 2. Small redesigns of older functionality.

These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off. Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you.
 3. Full module redesigns due to the need of serious improvement

This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc. These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new. This is preferred, since then new and old exist together. It avoids actually breaking anybody's code. If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it.
Jul 12 2011
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Jonathan M Davis, el 12 de julio a las 18:12 me escribiste:
 When a symbol has been deprecated, -d is required to compile any code
 using that symbol. So, deprecation breaks code. You either have to
 change your code so that it doesn't use the deprecated symbol, or you
 have to change your build scripts to use -d. In either case, deprecating
 a symbol without warning is going to cause problems for anyone
 maintaining code which uses that symbol.

If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.

Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D.

So then, why don't we fix it (patch attached, you can apply it with 'git am file'). I think -di is the real solution to the problem. Things are deprecated or not, and people want to be informed if they are using something deprecated or not. Scheduled for deprecation seems to be a way to say "show me a deprecation message", not a real "state".
 When a symbol is deprecated, it's an error to use it unless you compile with -
 d. So, there is no warning about using deprecated stuff. It's an outright 
 error. It just so happens that you can turn it off if you need to (hopefully 
 as a quick fix). And given that deprecating a symbol introduces errors into 
 the code of anyone who uses that symbol, informing people ahead of time gives 
 them the opportunity to change their code before it breaks. The result is a 
 much smoother process.

OK, then we should fix the compiler (again, patch attached). -di is the solution. My patch doesn't change the defaults, but if people think is better to show deprecation errors by default, it can be trivially changed.
 1. Something is scheduled for deprecation, so programmers then have the time 
 to figure out what they're going to do to change their code, and they have 
 time to make the changes. Nothing breaks. No one is forced to make immediate 
 changes.

This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler!
 2. The symbol is then deprecated. Anyone who did not take the time to make 
 changes as they were told that they were going to have to do then has broken 
 code, but they have the quick fix of compiling with -d if they need to. 
 They're still going to have to figure out what they're going to do about 
 changing their code, and they're forced to look at the problem at least far 
 enough to enable -d, but their code can still work with some changes to their 
 build scripts.
 
 3. The symbol is outright removed. Programmers have had ample time to change 
 their code, and if they haven't, they now have to. But they were told that the 
 symbol was going away and had to have made changes to their build scripts to 
 even use it this long, so the developer of the library hasn't just screwed 
 them over.
 
 The idea is to provide a smooth path for necessary changes. And just 
 deprecating something out of the blue does _not_ do that.

Unless we fix the compiler :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- All evidence has been buried All tapes have been erased But your footsteps give you away So you're backtracking
Jul 12 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-12 13:52, Leandro Lucarella wrote:
 Jonathan M Davis, el 12 de julio a las 18:12 me escribiste:
 When a symbol has been deprecated, -d is required to compile any code
 using that symbol. So, deprecation breaks code. You either have to
 change your code so that it doesn't use the deprecated symbol, or you
 have to change your build scripts to use -d. In either case,
 deprecating a symbol without warning is going to cause problems for
 anyone maintaining code which uses that symbol.

If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.

Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D.

So then, why don't we fix it (patch attached, you can apply it with 'git am file'). I think -di is the real solution to the problem. Things are deprecated or not, and people want to be informed if they are using something deprecated or not. Scheduled for deprecation seems to be a way to say "show me a deprecation message", not a real "state".
 When a symbol is deprecated, it's an error to use it unless you compile
 with - d. So, there is no warning about using deprecated stuff. It's an
 outright error. It just so happens that you can turn it off if you need
 to (hopefully as a quick fix). And given that deprecating a symbol
 introduces errors into the code of anyone who uses that symbol,
 informing people ahead of time gives them the opportunity to change
 their code before it breaks. The result is a much smoother process.

OK, then we should fix the compiler (again, patch attached). -di is the solution. My patch doesn't change the defaults, but if people think is better to show deprecation errors by default, it can be trivially changed.
 1. Something is scheduled for deprecation, so programmers then have the
 time to figure out what they're going to do to change their code, and
 they have time to make the changes. Nothing breaks. No one is forced to
 make immediate changes.

This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler!
 2. The symbol is then deprecated. Anyone who did not take the time to
 make changes as they were told that they were going to have to do then
 has broken code, but they have the quick fix of compiling with -d if
 they need to. They're still going to have to figure out what they're
 going to do about changing their code, and they're forced to look at the
 problem at least far enough to enable -d, but their code can still work
 with some changes to their build scripts.
 
 3. The symbol is outright removed. Programmers have had ample time to
 change their code, and if they haven't, they now have to. But they were
 told that the symbol was going away and had to have made changes to
 their build scripts to even use it this long, so the developer of the
 library hasn't just screwed them over.
 
 The idea is to provide a smooth path for necessary changes. And just
 deprecating something out of the blue does _not_ do that.

Unless we fix the compiler :)

This doesn't really fix the problem. Deprecating something is still going to break code unless people actively try and avoid it by using -di, so deprecating stuff without informing people beforehand is going to break a lot of code. Perhaps the language should be change so that using deprecated stuff generates a warning rather than an error, but unless you change the default behavior, the original problem still stands. If you want how the language treats deprecated to change, then feel free to create a pull request and try and talk Walter into it. Arguably, warning about deprecation and then only failing to compile when the deprecated stuff is actually removed is the better way to handle things. But that's not how D is designed (probably at least in part because Walter doesn't really believe in warnings). So, feel free to try and talk Walter into it, but unless the default behavior is changed, deprecating something is going to silently break people's code unless you tell them about it first (which is the point of scheduling something for deprecation). - Jonathan M Davis
Jul 12 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-12 15:09, Adam D. Ruppe wrote:
 Jonathan M Davis wrote:
 Deprecating something is still going to break code

Breaking with deprecated is an entirely different kind of breakage than removing something. deprecated means simply "please don't use this specific thing". You can tell it "shut up I know better than you" and be on your way. It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too.

True. But Walter has been pretty insistent that things not be deprecated without warning first, because code which compiled perfectly before doesn't anymore, even if all you have to do is change your build scripts. Now, as for the "scheduled for deprecation" messages, we can stop doing that. But then the documentation is going to be the only thing warning anyone, and then code is going to get broken when stuff is actually deprecated. Given the fact that you can use -d, that's not the end of the world. But it does mean that deprecation is going to tend to come out of nowhere for most people, and Walter has been very adamant about avoiding suddenly breaking people's code - even by requiring them to add -d to their build scripts. So, if most people don't want the messages, then the messages will go away. But that means that people actually need to pay attention to the changelog and documentation.
 Here's my preference list for changes:
 
 Top preference: don't change stuff.
 
 Next: use the deprecated attribute
 
 Next: versioned scheduled to be deprecated messages. I don't like
 being spammed every time I compile.
 
 Next: scheduled to be deprecated messages as they are now
 
 Last: removing it entirely. (this should be very, very rare
 especially if we want to be called stable. Nothing has pissed me
 off more with the last few releases than Phobos losing
 functionality.)

The current plan is that _everything_ which gets deprecated will be removed. Stuff which is deprecated is not intended to stick around. Now, it should be pretty rare that deprecated stuff doesn't have a replacement. Outright removing functionality should be very rare indeed. It may happen in a few cases where the functionality just isn't generally useful, but overall, it should be rare. Deprecation is likely to fall primarily in 3 categories at this point: 1. Renaming stuff to follow Phobos' naming conventions. A lot of this was fixed with 2.054, but there's still some left to do. For the most part though, this should be a set of fixes which will be done fairly soon and then we won't have to make those kind of changes again. 2. Small redesigns of older functionality. The prime case that I can think of is that there has been talk of replacing the use of patterns in std.string with uses of std.regex.Regex. 3. Full module redesigns due to the need of serious improvement. std.datetime replacing std.date would be a prime example of this, but there are a few other modules which are supposed to be redesigned (e.g. std.xml and std.stream). The idea at least is that these sort of changes should be taking place fairly soon and that we then won't need to do any of that kind of thing anymore (or at least only very rarely). The review process should catch most of these sort of issues before they actually get into Phobos in the first place. But some code has not aged well as D and Phobos have changed, and Phobos has not always been consistent in naming, and that needs to be fixed sooner rather than later. - Jonathan M Davis
Jul 12 2011
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el 12 de julio a las 21:51 me escribiste:
 If you want how the language treats deprecated to change, then feel free to 
 create a pull request and try and talk Walter into it. Arguably, warning about 
 deprecation and then only failing to compile when the deprecated stuff is 
 actually removed is the better way to handle things. But that's not how D is 
 designed (probably at least in part because Walter doesn't really believe in 
 warnings). So, feel free to try and talk Walter into it, but unless the 
 default behavior is changed, deprecating something is going to silently break 
 people's code unless you tell them about it first (which is the point of 
 scheduling something for deprecation).

So, your solution is issuing warnings behind the compiler and Walter's back. Great! I love this! Now I remember why I loved D so much =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El amor es como una reina ortopédica. -- Poroto
Jul 12 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 12 July 2011 23:38:10 Adam D. Ruppe wrote:
 Jonathan M Davis wrote:
 The current plan is that _everything_ which gets deprecated will
 be removed.

What's the reason for removing things? Surely it's not disk space! Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence. Painful changes though, are, well, painful.
 1. Renaming stuff to follow Phobos' naming conventions.

These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name). Do it fast, feel the brief pain, and move on.

Hmm. I don't think that Walter would be very happy about that, since it does immediately break code, but as long as the name change is easily found by the spellchecker, it wouldn't be a big deal to fix. So, under at least some circumstances, that may be acceptable. Regardless, it could be grounds for making the deprecation cycle for renaming relatively short instead of around 1 year as is the current plan for deprecation in general.
 2. Small redesigns of older functionality.

These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off. Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you.
 3. Full module redesigns due to the need of serious improvement

This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc. These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new. This is preferred, since then new and old exist together. It avoids actually breaking anybody's code. If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it.

At this point, I expect that the module rewrites are going to generally be full-on, completely incompatible rewrites. Fixing the API is one of the major reasons for the rewrites (particularly when converting a module to being range-based as is going to occur with std.stream), so just changing the implementation isn't going to cut it. It may be that in some cases, it's essentially a rewrite of a broken implementation, but I'm not aware of any such case at the moment. These are definitely cases, however, where the full deprecation cycle is going to be used, so there should be plenty of time to fix code. Hopefully, these changes get done fairly soon, but some of them don't seem to be going anywhere yet in spite of major discussions about them (e.g. std.stream). They're also the most work to do, so while I would expect most of the #1 and #2 types of deprecations to occur fairly soon for the most part, the full module rewrites could take a while, which is unfortunate. Off the top of my head, I know that std.xml, std.stream, std.path, and std.json are going to get rewrites on some level, and std.container could get some major rewrites depending on what Andrei does with memory management in it, though what it needs primarily is new containers. Also, Andrei thinks that std.encoding is a failed experiment which needs to be redone, so that's probably going to need to be rewritten at some point. And as I understand it, all of those except for std.stream and std.encoding have someone actively working on them (though maybe Andrei has been working on std.stream too; I don't know). So, hopefully it won't be too much longer before they're done, but it could also be a while unfortunately. So, anyway, there are some module rewrites to be done, and they're likely to be pretty major for better or worse. But once those are done, with the review process vetting new modules, deprecation issues like these should be far rarer, and Phobos should be heading towards stability. - Jonathan M Davis
Jul 12 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 12 July 2011 19:18:10 Leandro Lucarella wrote:
 Jonathan M Davis, el 12 de julio a las 21:51 me escribiste:
 If you want how the language treats deprecated to change, then feel free
 to create a pull request and try and talk Walter into it. Arguably,
 warning about deprecation and then only failing to compile when the
 deprecated stuff is actually removed is the better way to handle
 things. But that's not how D is designed (probably at least in part
 because Walter doesn't really believe in warnings). So, feel free to
 try and talk Walter into it, but unless the default behavior is
 changed, deprecating something is going to silently break people's code
 unless you tell them about it first (which is the point of scheduling
 something for deprecation).

So, your solution is issuing warnings behind the compiler and Walter's back. Great! I love this! Now I remember why I loved D so much =P

Nothing is being done behind anyone's back. It was Walter who pushed for stuff to be scheduled for deprecation before being actually deprecated, because he didn't want code breaking on people without any warning. We decided to use pragmas to present messages to the user informing them of the impending deprecation, because the language doesn't currently have anything built in with the concept of "scheduled for deprecation." It was either that or not warn about the impending deprecation except in the changelog and documentation, in which case, anyone who doesn't pay enough attention to those would still end up with their code being broken without warning when the symbols are actually deprecated. So, we went for the messages. If the majority of people would prefer not to have the messages and risk having their code break when something is deprecated, because they missed the notice in the changelog or documentation, then the messages will go away. But we thought that they were a good idea, so we put them in there. None of this is trying to circumvent Walter or the compiler. - Jonathan M Davis
Jul 13 2011
prev sibling next sibling parent reply &#1052;&#1080;&#1093;&#1072;&#1080;&#1083; &#1057;&#1090;&#1088;&#1072;&#1096;&#1091;&#1085; <nope nope.com> writes:
Looks like it fails to build under Linux using linux.mak makefile due to missing
intrange.c / intrange.o in file lists. Linking stage errors. When I add them
manually, everything works like a charm.
Could this one be fixed?
Best Regards,
Mihail
Jul 13 2011
next sibling parent Trass3r <un known.com> writes:
 Looks like it fails to build under Linux using linux.mak makefile due to  
 missing
 intrange.c / intrange.o in file lists. Linking stage errors. When I add  
 them
 manually, everything works like a charm.

I think compiling it worked just fine for me.
Jul 13 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/13/2011 9:58 AM, &#1052 wrote:
 Looks like it fails to build under Linux using linux.mak makefile due to
missing
 intrange.c / intrange.o in file lists. Linking stage errors. When I add them
 manually, everything works like a charm.
 Could this one be fixed?

Use posix.mak for the linux builds now.
Jul 13 2011
next sibling parent Extrawurst <spam extrawurst.org> writes:
Is this really that much impressive considering the fact that you 
compare results where the most work is done in the linked DLL itself no 
matter what code calls it, whether it is D or C, Debug or Release ??

On 14.07.2011 00:26, Andrej Mitrovic wrote:
 Damn, I am getting some impressive results comparing VC C++ builds and
 DMD D builds. I'm using the PortAudio library and a stress-test that
 comes with the project. It tries to generate as many sinewaves as
 possible until some maximum is reached. The PortAudio C DLL library is
 built in release mode, and is then implicitly linked with a C or D
 project. Here's the results:

 Stops on 500 max sines, or 0.80 max cpu.

 C debug:
 numSines = 229, CPU load = 0.802464  // cpu max reached

 C release:
 numSines = 500, CPU load = 0.793717  // max sines reached

 D debug:
 numSines = 258, CPU load = 0.800412  // cpu max reached

 D release:
 numSines = 500, CPU load = 0.629622  // max sines reached


 Notice how the C version barely made it to 500 sines in release mode
 (almost hit 0.80 CPU), but the D version had plenty of free CPU left
 (this is all done on a single core).

 I've enabled debug symbols and explicitly enabled floating-point
 exceptions in debug builds in the realtime-priority callback function,
 via:
      version (Debug)
      {
          import std.math;
          FloatingPointControl fpc;
          fpc.enableExceptions(FloatingPointControl.severeExceptions);
      }

 and that still beats C's debug build by a small margin. There were 3
 function macros which I've converted to auto templates, I think those
 got inlined in release mode. I'm using exceptions in the D version
 compared to C's use of goto's.

 Here's the C version code: http://codepad.org/4ERFVcSS
 And the D version: http://codepad.org/a7XL8wNW

 D debug switches (I had to use Debug instead of debug due to a
 critical bug): -g -version=Debug
 D release switches: -release -inline -O -noboundscheck

 Anyway if you want to try it yourself (Windows only for now), do:
 git clone https://github.com/AndrejMitrovic/DPortAudio

 cd and run \portaudio\build.bat
 cd and run \samples\build.bat

 The C examples are in the PortAudio project and if you want to compare
 with those you'll have to build them yourself.

Jul 13 2011
prev sibling next sibling parent &#1052;&#1080;&#1093;&#1072;&#1080;&#1083; &#1057;&#1090;&#1088;&#1072;&#1096;&#1091;&#1085; <nope nope.com> writes:
Is there any reason for linux.mak to still exist there then?
http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated
then
and I really would like to get it right - maintaining dmd2 in Arch Linux User
Repository is my responsibility ( and I was using linux.mak till now ).
Jul 14 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 14 July 2011 12:44:29 &#1052; &#1080; &#1093; &#1072; &#1080; 
&#1083; &#1057; &#1090; &#1088; &#1072; &#1096; &#1091; &#1085; wrote:
 Is there any reason for linux.mak to still exist there then?
 http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated
 then and I really would like to get it right - maintaining dmd2 in Arch
 Linux User Repository is my responsibility ( and I was using linux.mak till
 now ).

It's not in github. I expect that it's a result of Walter not creating the zip file from scratch every time. So, it was cruft that didn't get cleaned out. - Jonathan M Davis
Jul 14 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Damn, I am getting some impressive results comparing VC C++ builds and
DMD D builds. I'm using the PortAudio library and a stress-test that
comes with the project. It tries to generate as many sinewaves as
possible until some maximum is reached. The PortAudio C DLL library is
built in release mode, and is then implicitly linked with a C or D
project. Here's the results:

Stops on 500 max sines, or 0.80 max cpu.

C debug:
numSines = 229, CPU load = 0.802464  // cpu max reached

C release:
numSines = 500, CPU load = 0.793717  // max sines reached

D debug:
numSines = 258, CPU load = 0.800412  // cpu max reached

D release:
numSines = 500, CPU load = 0.629622  // max sines reached


Notice how the C version barely made it to 500 sines in release mode
(almost hit 0.80 CPU), but the D version had plenty of free CPU left
(this is all done on a single core).

I've enabled debug symbols and explicitly enabled floating-point
exceptions in debug builds in the realtime-priority callback function,
via:
    version (Debug)
    {
        import std.math;
        FloatingPointControl fpc;
        fpc.enableExceptions(FloatingPointControl.severeExceptions);
    }

and that still beats C's debug build by a small margin. There were 3
function macros which I've converted to auto templates, I think those
got inlined in release mode. I'm using exceptions in the D version
compared to C's use of goto's.

Here's the C version code: http://codepad.org/4ERFVcSS
And the D version: http://codepad.org/a7XL8wNW

D debug switches (I had to use Debug instead of debug due to a
critical bug): -g -version=Debug
D release switches: -release -inline -O -noboundscheck

Anyway if you want to try it yourself (Windows only for now), do:
git clone https://github.com/AndrejMitrovic/DPortAudio

cd and run \portaudio\build.bat
cd and run \samples\build.bat

The C examples are in the PortAudio project and if you want to compare
with those you'll have to build them yourself.
Jul 13 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It's a simplistic test, I agree.

The work done in PortAudio is initalization and release of hardware,
and conversion of different sample rates and buffer sizes, and buffer
types, when necessary.

The Pa_GetStreamCpuLoad() call measures how long it takes for
patestCallback() to finish and based on that calculates the CPU usage.
Jul 13 2011
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 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

The new CTFE docs got left out somehow.
Jul 20 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2011 2:29 PM, Don wrote:
 The new CTFE docs got left out somehow.

Not sure what you're referring to?
Jul 20 2011
parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 On 7/20/2011 2:29 PM, Don wrote:
 The new CTFE docs got left out somehow.

Not sure what you're referring to?

Sorry, it seems something went wrong with my repository. When I pushed, it didn't push to anything... I'll redo it.
Jul 21 2011