View mode: basic / threaded / horizontal-split · Log in · Help
November 04, 2012
version(deprecated)?
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?
November 04, 2012
Re: version(deprecated)?
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.
November 04, 2012
Re: version(deprecated)?
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
November 04, 2012
Re: version(deprecated)?
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';
November 04, 2012
Re: version(deprecated)?
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
November 05, 2012
Re: version(deprecated)?
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...
November 05, 2012
Re: version(deprecated)?
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).
November 05, 2012
Re: 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.
November 06, 2012
Re: version(deprecated)?
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.
December 22, 2012
Re: version(deprecated)?
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.
Top | Discussion index | About this forum | D home