www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - deprecate deprecated?

reply Walter Bright <newshound2 digitalmars.com> writes:
I know there's been some long term unhappiness about the deprecated attribute - 
it's all-or-nothing approach, poor messages, etc. Each change in it changes the 
language and the compiler.

Perhaps it could be done with a user defined attribute instead?

Anyone want to take on the challenge?
Nov 06 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 07-11-2012 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

Just fix the compiler behavior. https://github.com/D-Programming-Language/phobos/pull/904#issuecomment-10038838 -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 06 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 00:56, Walter Bright a écrit :
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That sound like a perfect use case for attribute.
Nov 06 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 06, 2012 15:56:09 Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each change
 in it changes the language and the compiler.
 
 Perhaps it could be done with a user defined attribute instead?
 
 Anyone want to take on the challenge?

And how would this interact with -d? It's one thing to give symbols attributes which can be examined at compile time. It's quite another to make it so that they don't compile without a specific compiler flag. I also don't really get what we gain from this. The only thing that I'm aware of which is really up for debate at this point is whether deprecated should result in an error or a warning. We even have messages for it now. Adding custom attributes which somehow indicate "scheduled for deprecation" or something like that might make sense, but what is beneficial abou removing deprecated itself from the language? How could that even work given that deprecated does more than simply tag the symbol with information? - Jonathan M Davis
Nov 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2012 5:12 PM, Jonathan M Davis wrote:
 And how would this interact with -d? It's one thing to give symbols attributes
 which can be examined at compile time. It's quite another to make it so that
 they don't compile without a specific compiler flag.

The -version flag can be used to turn things on and off in user code.
 I also don't really get what we gain from this. The only thing that I'm aware
 of which is really up for debate at this point is whether deprecated should
 result in an error or a warning. We even have messages for it now.

The gain is in reducing the demand for constant language changes. It's similar to the ability to now do GC introspection entirely in the library, rather than changing the compiler.
 Adding custom attributes which somehow indicate "scheduled for deprecation" or
 something like that might make sense, but what is beneficial abou removing
 deprecated itself from the language? How could that even work given that
 deprecated does more than simply tag the symbol with information?

I didn't say remove it. I said deprecate it.
Nov 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 04:40, Walter Bright wrote:

 I didn't say remove it. I said deprecate it.

I would assume that if a feature is getting deprecated it will be removed somewhere in the future, otherwise what's the reason for deprecating it? -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Perhaps it could be done with a user defined attribute instead?

Maybe we need more ways to better attach some semantics to UDAs :-) Bye, bearophile
Nov 06 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/12 1:56 AM, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

I don't think that's possible. One would need a mechanism to hook into all calls to a function (adorned with a specific attribute) and emit the message during compilation. That is missing. Andrei
Nov 06 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote:
 I don't think that's possible. One would need a mechanism to hook into all
calls
 to a function (adorned with a specific attribute) and emit the message during
 compilation. That is missing.

It would be interesting to see where those pain points are, and whether a general "hook" mechanism for user plugins would be a good idea.
Nov 06 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-07 04:41, Walter Bright wrote:

 It would be interesting to see where those pain points are, and whether
 a general "hook" mechanism for user plugins would be a good idea.

I think that with UDA in combination with AST macros it could work. deprecated("don't use this feature any more") int foo (int a) { return a + 3; } In this case deprecated would be a macro annotation/attribute or a declaration macro or what to call it. The macro would receive the AST of the declared language element, in this case the function. The AST return by the macro would be inserted instead of the declared function "foo". The deprecated macro would return an AST for the following code: int foo (int a) { static assert(false, "don't use this feature any more"); // use this for error // pragma(msg, "don't use this feature any more"); // use this for warning return a + 3; } Have a look at Scala macro annotations: http://scalamacros.org/future.html -- /Jacob Carlborg
Nov 07 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 11:42, Jacob Carlborg a écrit :
 On 2012-11-07 04:41, Walter Bright wrote:

 It would be interesting to see where those pain points are, and whether
 a general "hook" mechanism for user plugins would be a good idea.

I think that with UDA in combination with AST macros it could work. deprecated("don't use this feature any more") int foo (int a) { return a + 3; } In this case deprecated would be a macro annotation/attribute or a declaration macro or what to call it. The macro would receive the AST of the declared language element, in this case the function. The AST return by the macro would be inserted instead of the declared function "foo". The deprecated macro would return an AST for the following code: int foo (int a) { static assert(false, "don't use this feature any more"); // use this for error // pragma(msg, "don't use this feature any more"); // use this for warning return a + 3; } Have a look at Scala macro annotations: http://scalamacros.org/future.html

This is nice, but lack the possible to explore the internal of the function and to surgery in it :D Still a step forward.
Nov 07 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-07 15:08, deadalnix wrote:

 This is nice, but lack the possible to explore the internal of the
 function and to surgery in it :D

 Still a step forward.

I'm not entirely sure I understand. Do you mean that you won't see the output of the macro? In that case the compiler should have a flag for outputting the result of a macro. -- /Jacob Carlborg
Nov 07 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 18:58, Jacob Carlborg a écrit :
 On 2012-11-07 15:08, deadalnix wrote:

 This is nice, but lack the possible to explore the internal of the
 function and to surgery in it :D

 Still a step forward.

I'm not entirely sure I understand. Do you mean that you won't see the output of the macro? In that case the compiler should have a flag for outputting the result of a macro.

I'm talking about the ability for the macro to modify the macroed code, not only to wrap it.
Nov 07 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 20:32, deadalnix wrote:

 I'm talking about the ability for the macro to modify the macroed code,
 not only to wrap it.

I'm still not entirely sure what you mean but in most AST macro systems in other languages like Sacal, Nimrod and Nemerle you will get the complete AST of the function and can do whatever you want with it. It's just happens so that in this example it's enough to wrap the function. Actually, my "implementation" didn't wrap the function, it injected the "static assert" into the function body. -- /Jacob Carlborg
Nov 07 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 04:41, Walter Bright a écrit :
 On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote:
 I don't think that's possible. One would need a mechanism to hook into
 all calls
 to a function (adorned with a specific attribute) and emit the message
 during
 compilation. That is missing.

It would be interesting to see where those pain points are, and whether a general "hook" mechanism for user plugins would be a good idea.

The hook should be in D and CTFEable. This require an API provided in druntime or phobos. This is heavy work, but would definitively worth it.
Nov 07 2012
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 07.11.2012 03:55, schrieb Andrei Alexandrescu:
 On 11/7/12 1:56 AM, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

I don't think that's possible. One would need a mechanism to hook into all calls to a function (adorned with a specific attribute) and emit the message during compilation. That is missing. Andrei

If that was there though, it would also be very close to being able to define things like safe or nothrow or nogc as pure library functionality. This could offer some very interesting new static checking opportunities.
Nov 07 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 7 November 2012 at 02:55:38 UTC, Andrei 
Alexandrescu wrote:
 I don't think that's possible. One would need a mechanism to 
 hook into all calls to a function (adorned with a specific 
 attribute) and emit the message during compilation. That is 
 missing.

The attribute can be declared in library, but processed by the compiler - that's how C# works. See http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx
Nov 07 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 7 November 2012 at 13:43:39 UTC, Kagamin wrote:
 http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx
 http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx

Oh, and C# has ObsoleteAttribute http://msdn.microsoft.com/en-us/library/System.ObsoleteAttribute.aspx
Nov 07 2012
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
 I know there's been some long term unhappiness about the 
 deprecated attribute - it's all-or-nothing approach, poor 
 messages, etc. Each change in it changes the language and the 
 compiler.

I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning
Nov 06 2012
next sibling parent "Nathan M. Swan" <nathanmswan gmail.com> writes:
On 11/06/2012 10:03 PM, monarch_dodra wrote:
 On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning

I'm in favor of this; we can stop filling Phobos with "scheduled for deprecation," and just deprecate things. People using e.g. std.xml would get warnings but not have to refactor all their code at once. NMS
Nov 07 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 11-11-2012 14:18, Leandro Lucarella wrote:
 On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote:
 On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning

BTW, I already implemented that and is available as a pull request (I just called the option -di to follow the naming of -wi). https://github.com/D-Programming-Language/dmd/pull/1185 This pull request is available since July 2011 (was pull #248 back then), and I'm trying to convince Walter to merge it since then without any success. I'm really glad this finally came up here, maybe he finally understand the importance of having an usable deprecated implementation :) BTW, I think the default should be to have deprecations as warnings and not the other way around, but since I at least have the option to make them warnings, I'm fine.

Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries because it can break arbitrary build systems out there. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 11 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 11, 2012 16:16:33 David Nadlinger wrote:
 On Sunday, 11 November 2012 at 13:59:59 UTC, Alex R=C3=B8nne Petersen=

=20
 wrote:
 Yes, definitely warnings by default. The current system makes
 the deprecated keyword useless in practice for libraries

+1. Or even plus a whole lot more, if I had multiple votes.

They're obviously not regulated, so just go for typeof(vote).max. ;) - Jonathan M Davis
Nov 11 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis 
wrote:
 They're obviously not regulated, so just go for 
 typeof(vote).max. ;)

I'm afraid this would backfire – assuming that votes are integral, if somebody else also supported the issue after me, then the votes would either be reset or we would have undefined behavior. ;) David
Nov 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra 
wrote:
 -- : Deprecated stuff just can't be used
 -d : You can use deprecated stuff, but you get no warning
 -dw : You can use deprecated stuff, and are served with a 
 warning

Or some other default (I don't really care), but there needs to be a switch to say "don't use anything but the bleeding edge valid code". dw seems like a good "default" compromise, and the two others beeing user specified.
Nov 06 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 07, 2012 08:03:54 monarch_dodra wrote:
 On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
 I know there's been some long term unhappiness about the
 deprecated attribute - it's all-or-nothing approach, poor
 messages, etc. Each change in it changes the language and the
 compiler.

I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning

It would be better if deprecated stuff warned by default and only errored if you ask it to. The problem is that as it is now, if you mark anything is deprecated, you instantly break all code using it without warning. The only way that anyone can know if you intended for something to be deprecated and get the chance to fix their code before it breaks is if you tell them in the documenation or changelog or whatnot, which doesn't tell them where in their code they're using it, and is frequently going to be outright ignored. Certainly, from Phobos' perspective, the fact that deprecating something makes it so that it doesn't compile is a problem, because it means that as soon as we deprecate something, we break people's code (essentially without warning), and we don't want to do that. So, if we refuse to ever break people's code like that, we can't use deprecated. It would be nice to have a two-tiered approach where something is soft deprecated (and therefore warns) or is hard deprecated (and therefore gives an error), but that's been rejected in the past due to the extra complication that it adds. If we don't want to complicate the feature any further, then flags _could_ be used to control it, but then we'd probably need to make warn the default and have flags for making it an error or be ignored (or maybe even make it impossible to ignore, since it's a warning rather than an error). However, it would be bad if it were treated like a normal warning is and turned into an error with -w, because plenty of folks compile with -w, and so it would then once again become the case that deprecating anything would instantly break code without warning. As such, part of me wants to make it so that deprecated _never_ stops compilation, but you do bring up a good point that there are times that you need to (particularly where conditional compilation is concerned). - Jonathan M Davis
Nov 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-07 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

I think it's a bit too soon to start replacing language features with UDA. -- /Jacob Carlborg
Nov 07 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/11/2012 11:43, Jacob Carlborg a écrit :
 On 2012-11-07 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

I think it's a bit too soon to start replacing language features with UDA.

Yes, but that should be the goal !
Nov 07 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-07 15:10, deadalnix wrote:

 Yes, but that should be the goal !

Absolutely. -- /Jacob Carlborg
Nov 07 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
[OT] deprecated attribute is yet not correctly implemented by the compiler.

http://d.puremagic.com/issues/show_bug.cgi?id=7619

Kenji Hara

2012/11/7 Walter Bright <newshound2 digitalmars.com>:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each change in
 it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

Nov 07 2012
prev sibling next sibling parent "voiceofreason" <o3366043 rtrtr.com> writes:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
 I know there's been some long term unhappiness about the 
 deprecated attribute - it's all-or-nothing approach, poor 
 messages, etc. Each change in it changes the language and the 
 compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

Good plan. On a side note when can we expect some progress on stabilizing the language and fixing ~2000 bugs? After a couple of more random unnecessary breaking changes, or do you anticipate it happening before that?
Nov 07 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
On 07/11/12 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That *cannot* fix the problem. The problem is not with the deprecated attribute at all, it's with the command line switches.
Nov 08 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 08-11-2012 09:13, Don Clugston wrote:
 On 07/11/12 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That *cannot* fix the problem. The problem is not with the deprecated attribute at all, it's with the command line switches.

+1. -- Alex Rnne Petersen alex lycus.org http://lycus.org
Nov 08 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/8/2012 12:13 PM, Don Clugston пишет:
 On 07/11/12 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That *cannot* fix the problem. The problem is not with the deprecated attribute at all, it's with the command line switches.

That and it taking a looong time to add sensible "don't use 'this' use 'that'" messages to deprecated. -- Dmitry Olshansky
Nov 08 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2012 12:13 AM, Don Clugston wrote:
 That *cannot* fix the problem.
 The problem is not with the deprecated attribute at all, it's with the command
 line switches.

Of interest: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html Looks like another D feature moving into C++!
Nov 09 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 09-11-2012 19:06, Kagamin wrote:
 On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
 On 11/8/2012 12:13 AM, Don Clugston wrote:
 That *cannot* fix the problem.
 The problem is not with the deprecated attribute at all, it's with
 the command
 line switches.

Of interest: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html Looks like another D feature moving into C++!

I'd say, gcc's attribute system is used better than in D. http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes They use attributes for const, pure, nothrow, dllimport, while D uses keywords.

And they are tedious as hell to type. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 10 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/9/12, Walter Bright <newshound2 digitalmars.com> wrote:
 On 11/8/2012 12:13 AM, Don Clugston wrote:
 That *cannot* fix the problem.
 The problem is not with the deprecated attribute at all, it's with the
 command
 line switches.

Of interest: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html Looks like another D feature moving into C++!

They terk err jerbs!!
Nov 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 09, 2012 00:49:19 Walter Bright wrote:
 On 11/8/2012 12:13 AM, Don Clugston wrote:
 That *cannot* fix the problem.
 The problem is not with the deprecated attribute at all, it's with the
 command line switches.

Of interest: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html Looks like another D feature moving into C++!

One major difference in what they're describing vs what we have is that for us, deprecated immediately triggers an error, whereas for them, it's a warning by default. I think that we'd to well to change to that scheme to match theirs (though have whether it's treated as an error be kept separate from -w so that normal warnings because many people compile with it normally). That way, by default, deprecating something doesn't break people's code but rather simply encourages them to change it, and their code won't be broken until the symbol is actually remove from the library or they choose to compile with -dw (or whatever we name the switch that makes using deprecated symbols an error). As it stands, if we don't want to break anyone's code, we can't really use deprecated, whereas if it were changed to warn by default, we _could_ use it where appropriate and thereby encourage people to change their code but not break anyone's code. It also avoids the problem of people not being aware that something is going to be deprecated before their code stops compiling due to it being deprecated or removed, since right now, the only way to know if something is going to be deprecated is to read the changelog or documentation, which many people won't read. - Jonathan M Davis
Nov 09 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
 On 11/8/2012 12:13 AM, Don Clugston wrote:
 That *cannot* fix the problem.
 The problem is not with the deprecated attribute at all, it's 
 with the command
 line switches.

Of interest: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html Looks like another D feature moving into C++!

I'd say, gcc's attribute system is used better than in D. http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes They use attributes for const, pure, nothrow, dllimport, while D uses keywords.
Nov 09 2012
prev sibling parent reply "Leandro Lucarella" <leandro.lucarella sociomantic.com> writes:
On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
 On 07/11/12 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the 
 deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. 
 Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That *cannot* fix the problem. The problem is not with the deprecated attribute at all, it's with the command line switches.

Exactly, deprecated is one of those features that *needs* to be in the compiler, at least part of it. Because is not only about the deprecated attribute for user symbols, there are also deprecated constructs in the language, that only the compiler can detect and can emit messages for. Having deprecated as a core part of the language is not an option, is the only way to do it right, so why don't we just fix it in the compiler then? Adding the deprecated("message") syntax was a huge step forward. Now we just need an option to emit deprecations as warnings and that's it. It's already there, you just have to merge it :) https://github.com/D-Programming-Language/dmd/pull/1185
Nov 11 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 11-11-2012 14:09, Leandro Lucarella wrote:
 On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
 On 07/11/12 00:56, Walter Bright wrote:
 I know there's been some long term unhappiness about the deprecated
 attribute - it's all-or-nothing approach, poor messages, etc. Each
 change in it changes the language and the compiler.

 Perhaps it could be done with a user defined attribute instead?

 Anyone want to take on the challenge?

That *cannot* fix the problem. The problem is not with the deprecated attribute at all, it's with the command line switches.

Exactly, deprecated is one of those features that *needs* to be in the compiler, at least part of it. Because is not only about the deprecated attribute for user symbols, there are also deprecated constructs in the language, that only the compiler can detect and can emit messages for. Having deprecated as a core part of the language is not an option, is the only way to do it right, so why don't we just fix it in the compiler then? Adding the deprecated("message") syntax was a huge step forward. Now we just need an option to emit deprecations as warnings and that's it. It's already there, you just have to merge it :) https://github.com/D-Programming-Language/dmd/pull/1185

I'm against that pull request. Not because I think it isn't useful, but because I think it doesn't fix the problem. Usage of deprecated symbol(s) should be a warning by default and the new option should be used to turn that into an error; not the other way around. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 11 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 17-11-2012 13:53, Kagamin wrote:
 On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis wrote:
 Usage of deprecated symbol(s) should be a warning by default and the new
 option should be used to turn that into an error; not the other way
 around.

Agreed. Otherwise, you can't deprecate something without immediately breaking code, which means that if you're trying to never immediately break people's code when making a change (which is the position that Phobos is in), then you can't use deprecated.

fixing the broken code is as simple as make -DDFLAGS=-d

And that's the entire problem. People shouldn't have to go in and change anything to make code build just because something has been deprecated. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 17 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 18, 2012 11:00:09 Kagamin wrote:
 You compile with -d because previously the build broke, so you
 know you use deprecated features.

Except that then you forget about it and never get around to updating your code so that it doesn't use the deprecated features, and when they're removed, your code breaks. -d is arguably a rather evil flag actually, and there are some of us would wouldn't mind having it gone entirely. With deprecated warning, then code doesn't break immediately, and the programmer gets reminded that they need to update their code. It's just plain a better model. - Jonathan M Davis
Nov 18 2012
prev sibling next sibling parent "Leandro Lucarella" <leandro.lucarella sociomantic.com> writes:
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra 
wrote:
 On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright 
 wrote:
 I know there's been some long term unhappiness about the 
 deprecated attribute - it's all-or-nothing approach, poor 
 messages, etc. Each change in it changes the language and the 
 compiler.

I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated: For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road... I had proposed a "three state -d": -- : Deprecated stuff just can't be used -d : You can use deprecated stuff, but you get no warning -dw : You can use deprecated stuff, and are served with a warning

BTW, I already implemented that and is available as a pull request (I just called the option -di to follow the naming of -wi). https://github.com/D-Programming-Language/dmd/pull/1185 This pull request is available since July 2011 (was pull #248 back then), and I'm trying to convince Walter to merge it since then without any success. I'm really glad this finally came up here, maybe he finally understand the importance of having an usable deprecated implementation :) BTW, I think the default should be to have deprecations as warnings and not the other way around, but since I at least have the option to make them warnings, I'm fine.
Nov 11 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 11 November 2012 at 13:59:59 UTC, Alex Rønne Petersen 
wrote:
 Yes, definitely warnings by default. The current system makes 
 the deprecated keyword useless in practice for libraries

+1. Or even plus a whole lot more, if I had multiple votes. David
Nov 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 11, 2012 15:01:14 Alex R=C3=B8nne Petersen wrote:
 I'm against that pull request. Not because I think it isn't useful, b=

 because I think it doesn't fix the problem.
=20
 Usage of deprecated symbol(s) should be a warning by default and the =

 option should be used to turn that into an error; not the other way a=

Agreed. Otherwise, you can't deprecate something without immediately br= eaking=20 code, which means that if you're trying to never immediately break peop= le's=20 code when making a change (which is the position that Phobos is in), th= en you=20 can't use deprecated. "Scheduling" stuff for deprecation has helped, bu= t it=20 hasn't really fixed all that much. Making it so that deprecated emited = a=20 warning instead of an error and otherwise did not affect compilation _w= ould_ fix=20 it (as long as -w didn't affect it), but then a flag for making it an e= rror is=20 needed so that people can be sure that they've completely removed all=20= deprecated features from their code (due to how deprecated affects cond= itional=20 compilation). - Jonathan M Davis
Nov 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 11, 2012 23:06:45 David Nadlinger wrote:
 On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis
=20
 wrote:
 They're obviously not regulated, so just go for
 typeof(vote).max. ;)

I'm afraid this would backfire =E2=80=93 assuming that votes are integral, if somebody else also supported the issue after me, then the votes would either be reset or we would have undefined behavior. ;)

No. This is D. It wouldn't be undefined at all. It would just wrap arou= nd to=20 typeof(vote).min. That should be completely defined for integral types = (for=20 that matter, it's well-defined in C land too. It's just that you have i= ssues=20 with the size of the type changing depending on which machine you compi= le on).=20 I'm not sure what happens with non-integral types though. I _was_ prett= y much=20 assuming an integral type. But yes, that would be a problem, because you would have nullified all = future=20 votes. typeof(vote.max) / 2 it is then. ;) - Jonathan M Davis
Nov 11 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 11 November 2012 at 22:28:58 UTC, Jonathan M Davis 
wrote:
 for that matter, it's well-defined in C land too.

Signed integer overflow isn't well-defined in C; only operations on unsigned types are guaranteed to wrap around. And since people might also want to downvote a proposal… Anyway, what was the topic? ;) David
Nov 11 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis 
wrote:
 Agreed. Otherwise, you can't deprecate something without 
 immediately breaking
 code, which means that if you're trying to never immediately 
 break people's
 code when making a change (which is the position that Phobos is 
 in), then you
 can't use deprecated.

 [SNIP]

 - Jonathan M Davis

The problem with this approach is that the step after marking something deprecated is removing the function. So people using something deprecated go from - "warning: Don't use this" (yeah... whatever...) - "Your function has disappeared". (Oh oh) At this point, they're fucked bad because they can't even bypass the problem with an extra -d command line option, which (in my eyes) is "pretty please, I'll change it, just give me a bit more time". IMO, there *NEEDS* to be some way of saying - "this _will_ be deprecated soon (marked for deprecation), you should consider migrating to something else. here is you warning." and - "This is already deprecated. Here is your error. You can *still* use it with -d, but migrate away soon, because this function is about to disappear" ---- If you can't make this distinction, then you also run into the danger of not breaking anybody's code when deprecating stuff, but having to keep deprecated stuff around forever.
Nov 12 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, November 12, 2012 12:09:34 monarch_dodra wrote:
 IMO, there *NEEDS* to be some way of saying
 - "this _will_ be deprecated soon (marked for deprecation), you
 should consider migrating to something else. here is you warning."
 and
 - "This is already deprecated. Here is your error. You can
 *still* use it with -d, but migrate away soon, because this
 function is about to disappear"
 
 ----
 If you can't make this distinction, then you also run into the
 danger of not breaking anybody's code when deprecating stuff, but
 having to keep deprecated stuff around forever.

Sure, it would be nice to have that distinction, but regardless of what you do, if the user doesn't fix their code, it'll break eventually when the deprecated symbol is removed. Because we have -d, they can completely ignore deprecated stuff even though it currently gives an error, which puts them in exactly the same boat that they'll be if they use -d if using deprecated stuff is a warning, and if they don't use -d, they're always being bugged about it, so it's basically the same as -d now as far as compilation goes, but they'll be made aware of the problem. The _only_ downside that I see is that if someone is stupid enough to leave in a sea of warnings (which is much harder to do in D than other languages due to Walter's dislike of warnings), the deprecation messages might be buried. But as long as you can see them and/or you compile with -de (or whatever the flag is that makes them errors again), then I don't see problem. The fact that you go from warning to gone (if no extra flags are used) isn't a problem as far as I can see. It's really not that much different from what we have now as far as people ignoring fixing deprecated stuff goes. It just means that people's code won't break immediately when stuff is deprecated. And sure, there's a possibility that stuff will stick around for a ridiculously long time, but we have that problem _now_ when deprecated generates an error by default. - Jonathan M Davis
Nov 12 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis 
wrote:
 Usage of deprecated symbol(s) should be a warning by default 
 and the new
 option should be used to turn that into an error; not the 
 other way around.

Agreed. Otherwise, you can't deprecate something without immediately breaking code, which means that if you're trying to never immediately break people's code when making a change (which is the position that Phobos is in), then you can't use deprecated.

fixing the broken code is as simple as make -DDFLAGS=-d
Nov 17 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 17, 2012 13:53:45 Kagamin wrote:
 On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis
 
 wrote:
 Usage of deprecated symbol(s) should be a warning by default
 and the new
 option should be used to turn that into an error; not the
 other way around.

Agreed. Otherwise, you can't deprecate something without immediately breaking code, which means that if you're trying to never immediately break people's code when making a change (which is the position that Phobos is in), then you can't use deprecated.

fixing the broken code is as simple as make -DDFLAGS=-d

True, but you're still breaking code, and Walter is _very_ much against that. I think that if it were entirely up to him, no API would change ever. Also, if you start compiling with -d, then you have no idea what is and isn't deprecated, and then you're that much more screwed when a deprecated symbol is actually removed. It just would work a _lot_ better if deprecated warned by default. Then it's made clear that the code needs to be changed but the build isn't broken, and the maintainers have time to fix it before their code actually breaks and with the warnings still there reminding them rather than simply being made to go away with -d and then forgotten. - Jonathan M Davis
Nov 17 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Saturday, 17 November 2012 at 17:42:03 UTC, Alex Rønne 
Petersen wrote:
 And that's the entire problem.

 People shouldn't have to go in and change anything to make code 
 build just because something has been deprecated.

It's just an alternative compilation mode. And may be people shouldn't go in and enter admin password to install software? On Saturday, 17 November 2012 at 18:48:11 UTC, Jonathan M Davis wrote:
 Also, if
 you start compiling with -d, then you have no idea what is and 
 isn't
 deprecated, and then you're that much more screwed when a 
 deprecated symbol is
 actually removed.

You compile with -d because previously the build broke, so you know you use deprecated features.
Nov 18 2012