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 parent reply "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 

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



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


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


 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
parent reply "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
parent reply 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


=20
 +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
parent reply "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
parent reply 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. ;)


=20
 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
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 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 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 Rønne 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
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 parent reply "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
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 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 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=


ut

 because I think it doesn't fix the problem.
=20
 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 a=


round.

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
next sibling parent reply "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
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 parent reply "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
next sibling 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 reply "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
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 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