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
next sibling parent reply 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
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 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 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 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 reply "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
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
next sibling parent reply "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
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 reply "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
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 reply "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
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 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 parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
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.






 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.



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.
Jul 11 2011
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 reply "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
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 parent reply 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
parent reply 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
parent reply 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
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 Leandro Lucarella <luca llucax.com.ar> writes:
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
next sibling parent reply "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
next sibling 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 reply "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
parent reply 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
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 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 parent reply 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
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 parent reply 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
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 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 reply "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
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 reply "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
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 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 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
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
next sibling parent reply 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
parent reply 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
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Thanks!
Jul 12 2011
prev 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 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++;
 }


 auto ref changes the code generated for the function body, so it must be a
template.


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?


 Yes, it has to be that way. It's the difference between passing T* and T.


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 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
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 reply 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
parent reply 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
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 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 parent reply Walter Bright <newshound2 digitalmars.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?


Use posix.mak for the linux builds now.
Jul 13 2011
next sibling parent reply 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
parent reply 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
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 &#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
parent Jonathan M Davis <jmdavisProg gmx.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 ).


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 bearophile <bearophileHUGS lycos.com> writes:
Walter:

I was forgetting, DMD 2.054 has fulfilled this enhancement request too:
http://d.puremagic.com/issues/show_bug.cgi?id=5250

Bye,
bearophile
Jul 14 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