www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - version(deprecated)?

reply "monarch_dodra" <monarchdodra gmail.com> writes:
I'm wondering if there is a way to know you are in deprecated 
mode or not?

The deprecated attribute is great, because it gives a clear 
compile error (as opposed to a static if, which just hides the 
function completely).

But the attribute alone is not enough: I have a class with a 
deprecated method, which consumes a book-keeping attribute: Not 
only will this attribute exist even though it has become useless, 
but the other functions will keep updating this attribute, even 
though it has no more consumers.

What's more, I'd still want to unittest that function, but 
obviously, only when compiled in "-unittest -d".

So I have a problem.

--------
Finding out if the compilation mode is deprecated is easy enough:

//----
deprecated  property void deprecateExists(){}
enum deprecatedActive = is(typeof(deprecateExists));
//----

The thing is it's kind of dirty, and I wouldn't want to have to 
copy paste this in all of my modules, just to know whether or not 
deprecation is active...


--------
We've currently implemented "version(assert)" and 
"version(debug)". Do you think we should request having a 
"version(deprecated)"? I think it would be very helpful. Thoughts?
Nov 04 2012
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 4 November 2012 at 15:48:28 UTC, monarch_dodra wrote:

 We've currently implemented "version(assert)" and 
 "version(debug)". Do you think we should request having a 
 "version(deprecated)"? I think it would be very helpful. 
 Thoughts?


We also have version(unittest). version(deprecated) seems like a 
natural addition.
Nov 04 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-11-2012 16:48, monarch_dodra wrote:

 I'm wondering if there is a way to know you are in deprecated mode or not?

 The deprecated attribute is great, because it gives a clear compile
 error (as opposed to a static if, which just hides the function
 completely).

 But the attribute alone is not enough: I have a class with a deprecated
 method, which consumes a book-keeping attribute: Not only will this
 attribute exist even though it has become useless, but the other
 functions will keep updating this attribute, even though it has no more
 consumers.

 What's more, I'd still want to unittest that function, but obviously,
 only when compiled in "-unittest -d".

 So I have a problem.

 --------
 Finding out if the compilation mode is deprecated is easy enough:

 //----
 deprecated  property void deprecateExists(){}
 enum deprecatedActive = is(typeof(deprecateExists));
 //----

 The thing is it's kind of dirty, and I wouldn't want to have to copy
 paste this in all of my modules, just to know whether or not deprecation
 is active...


 --------
 We've currently implemented "version(assert)" and "version(debug)". Do
 you think we should request having a "version(deprecated)"? I think it
 would be very helpful. Thoughts?


https://github.com/D-Programming-Language/dmd/pull/1257

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Nov 04 2012
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 4 November 2012 17:27, Alex R=F8nne Petersen <alex lycus.org> wrote:

 On 04-11-2012 16:48, monarch_dodra wrote:

 I'm wondering if there is a way to know you are in deprecated mode or no=




t?

 The deprecated attribute is great, because it gives a clear compile
 error (as opposed to a static if, which just hides the function
 completely).

 But the attribute alone is not enough: I have a class with a deprecated
 method, which consumes a book-keeping attribute: Not only will this
 attribute exist even though it has become useless, but the other
 functions will keep updating this attribute, even though it has no more
 consumers.

 What's more, I'd still want to unittest that function, but obviously,
 only when compiled in "-unittest -d".

 So I have a problem.

 --------
 Finding out if the compilation mode is deprecated is easy enough:

 //----
 deprecated  property void deprecateExists(){}
 enum deprecatedActive =3D is(typeof(deprecateExists));
 //----

 The thing is it's kind of dirty, and I wouldn't want to have to copy
 paste this in all of my modules, just to know whether or not deprecation
 is active...


 --------
 We've currently implemented "version(assert)" and "version(debug)". Do
 you think we should request having a "version(deprecated)"? I think it
 would be very helpful. Thoughts?


 https://github.com/D-Programming-Language/dmd/pull/1257

 --
 Alex R=F8nne Petersen
 alex lycus.org
 http://lycus.org



I fail to see the use case.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Nov 04 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, November 04, 2012 16:48:26 monarch_dodra wrote:

 I'm wondering if there is a way to know you are in deprecated
 mode or not?
 
 The deprecated attribute is great, because it gives a clear
 compile error (as opposed to a static if, which just hides the
 function completely).
 
 But the attribute alone is not enough: I have a class with a
 deprecated method, which consumes a book-keeping attribute: Not
 only will this attribute exist even though it has become useless,
 but the other functions will keep updating this attribute, even
 though it has no more consumers.
 
 What's more, I'd still want to unittest that function, but
 obviously, only when compiled in "-unittest -d".


Putting deprecated on the unittest block takes care of the unit testing 
problem. However, without a version(deprecated), I don't know how you'd deal 
with alternate versions of the same thing. Usually what happens in that case 
is that you create an entirely new type or function with a different name.

Actually, if you use static if with __traits(compiles, blah) to check whether 
the deprecated bit compiles, then you could do it without version(deprecated), 
but it may be worth adding version(deprecated) just the same.

- Jonathan M Davis
Nov 04 2012
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 4 November 2012 at 22:30:31 UTC, Jonathan M Davis
wrote:

 [SNIP]

 Actually, if you use static if with __traits(compiles, blah) to 
 check whether
 the deprecated bit compiles, then you could do it without 
 version(deprecated),
 but it may be worth adding version(deprecated) just the same.

 - Jonathan M Davis


I had thought of that, but the problem is that if you
accidentally break "blah", you're going to get blind-sided...
Nov 04 2012
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 04 Nov 2012 16:48:26 +0100
schrieb "monarch_dodra" <monarchdodra gmail.com>:


 I'm wondering if there is a way to know you are in deprecated 
 mode or not?
 
 The deprecated attribute is great, because it gives a clear 
 compile error (as opposed to a static if, which just hides the 
 function completely).
 
 But the attribute alone is not enough: I have a class with a 
 deprecated method, which consumes a book-keeping attribute: Not 
 only will this attribute exist even though it has become useless, 
 but the other functions will keep updating this attribute, even 
 though it has no more consumers.
 
 What's more, I'd still want to unittest that function, but 
 obviously, only when compiled in "-unittest -d".
 
 So I have a problem.
 
 --------
 Finding out if the compilation mode is deprecated is easy enough:
 
 //----
 deprecated  property void deprecateExists(){}
 enum deprecatedActive = is(typeof(deprecateExists));
 //----
 
 The thing is it's kind of dirty, and I wouldn't want to have to 
 copy paste this in all of my modules, just to know whether or not 
 deprecation is active...
 
 
 --------
 We've currently implemented "version(assert)" and 
 "version(debug)". Do you think we should request having a 
 "version(deprecated)"? I think it would be very helpful. Thoughts?
 
 


As deprecated now allows optional messages some folks have suggested to
make deprecated behave like in other languages: Warn if something
deprecated is used, do not print warnings if compiling with
-deprecated.
This would conflict with your proposed usage of version(deprecated).
Nov 05 2012
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 5 November 2012 at 08:53:48 UTC, Johannes Pfau wrote:

 Am Sun, 04 Nov 2012 16:48:26 +0100
 schrieb "monarch_dodra" <monarchdodra gmail.com>:


 I'm wondering if there is a way to know you are in deprecated 
 mode or not?
 
 The deprecated attribute is great, because it gives a clear 
 compile error (as opposed to a static if, which just hides the 
 function completely).
 
 But the attribute alone is not enough: I have a class with a 
 deprecated method, which consumes a book-keeping attribute: 
 Not only will this attribute exist even though it has become 
 useless, but the other functions will keep updating this 
 attribute, even though it has no more consumers.
 
 What's more, I'd still want to unittest that function, but 
 obviously, only when compiled in "-unittest -d".
 
 So I have a problem.
 
 --------
 Finding out if the compilation mode is deprecated is easy 
 enough:
 
 //----
 deprecated  property void deprecateExists(){}
 enum deprecatedActive = is(typeof(deprecateExists));
 //----
 
 The thing is it's kind of dirty, and I wouldn't want to have 
 to copy paste this in all of my modules, just to know whether 
 or not deprecation is active...
 
 
 --------
 We've currently implemented "version(assert)" and 
 "version(debug)". Do you think we should request having a 
 "version(deprecated)"? I think it would be very helpful. 
 Thoughts?
 
 


 As deprecated now allows optional messages some folks have 
 suggested to
 make deprecated behave like in other languages: Warn if 
 something
 deprecated is used, do not print warnings if compiling with
 -deprecated.
 This would conflict with your proposed usage of 
 version(deprecated).


Is that even possible? I mean, if I deprecate R.index, then what 
is the value of isRandomAccessRange!R? If I call algorithm 
"find(r1, r2);", then will I get a message I'm using a deprecated 
branch?

Wouldn't the proposal be better served as:
-- : Deprecated stuff just can't be used
-d : You can use deprecated stuff, and you get no warning 
whatsoever
-dw : You can use deprecated stuff, but are served with a warning

In that context, we'd keep a clear [w|w/o] deprecated, and my 
proposal would not conflict either.
Nov 05 2012
parent Johannes Pfau <nospam example.com> writes:
Am Mon, 05 Nov 2012 10:48:47 +0100
schrieb "monarch_dodra" <monarchdodra gmail.com>:


 On Monday, 5 November 2012 at 08:53:48 UTC, Johannes Pfau wrote:

 Am Sun, 04 Nov 2012 16:48:26 +0100
 schrieb "monarch_dodra" <monarchdodra gmail.com>:


 I'm wondering if there is a way to know you are in deprecated 
 mode or not?
 
 The deprecated attribute is great, because it gives a clear 
 compile error (as opposed to a static if, which just hides the 
 function completely).
 
 But the attribute alone is not enough: I have a class with a 
 deprecated method, which consumes a book-keeping attribute: 
 Not only will this attribute exist even though it has become 
 useless, but the other functions will keep updating this 
 attribute, even though it has no more consumers.
 
 What's more, I'd still want to unittest that function, but 
 obviously, only when compiled in "-unittest -d".
 
 So I have a problem.
 
 --------
 Finding out if the compilation mode is deprecated is easy 
 enough:
 
 //----
 deprecated  property void deprecateExists(){}
 enum deprecatedActive = is(typeof(deprecateExists));
 //----
 
 The thing is it's kind of dirty, and I wouldn't want to have 
 to copy paste this in all of my modules, just to know whether 
 or not deprecation is active...
 
 
 --------
 We've currently implemented "version(assert)" and 
 "version(debug)". Do you think we should request having a 
 "version(deprecated)"? I think it would be very helpful. 
 Thoughts?
 
 


 As deprecated now allows optional messages some folks have 
 suggested to
 make deprecated behave like in other languages: Warn if 
 something
 deprecated is used, do not print warnings if compiling with
 -deprecated.
 This would conflict with your proposed usage of 
 version(deprecated).


 
 Is that even possible? I mean, if I deprecate R.index, then what 
 is the value of isRandomAccessRange!R?


Always true, whether compiled with -deprecated or without.


 If I call algorithm 
 "find(r1, r2);", then will I get a message I'm using a deprecated 
 branch?


Yes, IIRC that's how it's supposed to work. It would leave all code in
but warn as soon as it's used. But for generic code which could use
both deprecated and non-deprecated branches that would indeed be
annoying. I'm not sure if anyone really thought this through.


 Wouldn't the proposal be better served as:
 -- : Deprecated stuff just can't be used
 -d : You can use deprecated stuff, and you get no warning 
 whatsoever
 -dw : You can use deprecated stuff, but are served with a warning
 
 In that context, we'd keep a clear [w|w/o] deprecated, and my 
 proposal would not conflict either.


Probably, I'm not sure as I personally don't have any problems with the
current deprecated behavior. Somebody else would have to chime in.
Nov 06 2012
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 5 November 2012 at 08:53:48 UTC, Johannes Pfau wrote:

 As deprecated now allows optional messages some folks have 
 suggested to
 make deprecated behave like in other languages: Warn if 
 something
 deprecated is used, do not print warnings if compiling with
 -deprecated.
 This would conflict with your proposed usage of 
 version(deprecated).


I've thought about this some more, and my conclusion is: 
irrelevant.

At the end of the say, when the code is compiling, it can be in 
only one of two states:
* deprecated methods are illegal
* deprecated methods are legal (with or without warnings: who 
cares)

So basically, without worrying about how the "-d" switch works 
(or will work in the future), we can have a version(deprecated) 
that returns true if "using deprecated stuff is legal" and false 
otherwise.

Basically, I think having a version(deprecated) and a "warn when 
using deprecated stuff" are two orthogonal concepts that can 
coexist without clashing.
Dec 22 2012