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 ve
-
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 requ
t; 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 "vers
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(depreca
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
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. Th
x27;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 deprecate
t;> 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 implemente
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 wi
10 matches
Mail list logo