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?

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.

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

On 4 November 2012 17:27, Alex Rønne 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 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


I fail to see the use case.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

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

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

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

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.

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.

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.