Okay. From the looks of it, at same point relatively soon, we're going to have the ability to give deprecated a message, which will improve deprecated considerably, but we have not agreed on any changes to deprecated which would support "scheduled for deprecation." We have been using pragmas to add messages to some of the stuff that's been scheduled for deprecation, but that only works with templated stuff, and some people have been complaining about it, particularly since the messages don't (and can't) tell them _where_ in their code the soon to be deprecated stuff is being used. Given the complaints and the fact that we can't actually use messages unilaterally with stuff which has been scheduled for deprecation, at this point, I'm inclined to think that we'd be better off just removing the pragmas on stuff that's been scheduled for deprecation. Is anyone opposed to this?

If not, then I'd like to make the changes ASAP so that they can make it into the next release. I don't think that anything else has been scheduled for deprecation since the last release, but since the messages have been causing complaints, I'd like to get the situation settled, and if we're not going to be improving deprecated to deal with "scheduled for deprecation" anytime soon, then I think that we should just drop the practice of using pragmas for it.

I'd leave in the pragmas on the stuff which has already been deprecated until deprecated can take a message, but for the "scheduled for deprecation" stuff, I think that we should remove the pragmas, since they appear to be primarily annoying people.

So, in the long run, when deprecating stuff, we'd do it like so:

1. Mark something as scheduled for deprecated in the documentation and the changelog.

2. Mark it as deprecated and give deprecated an informative message.

3. Remove the deprecated symbol.

There would be no messages until #2. In any case, this is probably a bit long for a fairly simple question: is anyone opposed to my going and removing all of the "scheduled for deprecation" pragmas so that they aren't in the next release, given that pretty much everyone who mentions them doesn't like them?

- Jonathan M Davis

I would be for your proposal. Knowing that it will be deprecated is not too useful when you don't know where it is used.

On Sat, Oct 22, 2011 at 3:17 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> Okay. From the looks of it, at same point relatively soon, we're going to have the ability to give deprecated a message, which will improve deprecated considerably, but we have not agreed on any changes to deprecated which would support "scheduled for deprecation." We have been using pragmas to add messages to some of the stuff that's been scheduled for deprecation, but that only works with templated stuff, and some people have been complaining about it, particularly since the messages don't (and can't) tell them _where_ in their code the soon to be deprecated stuff is being used. Given the complaints and the fact that we can't actually use messages unilaterally with stuff which has been scheduled for deprecation, at this point, I'm inclined to think that we'd be better off just removing the pragmas on stuff that's been scheduled for deprecation. Is anyone opposed to this?
>
> If not, then I'd like to make the changes ASAP so that they can make it into the next release. I don't think that anything else has been scheduled for deprecation since the last release, but since the messages have been causing complaints, I'd like to get the situation settled, and if we're not going to be improving deprecated to deal with "scheduled for deprecation" anytime soon, then I think that we should just drop the practice of using pragmas for it.
>
> I'd leave in the pragmas on the stuff which has already been deprecated until deprecated can take a message, but for the "scheduled for deprecation" stuff, I think that we should remove the pragmas, since they appear to be primarily annoying people.
>
> So, in the long run, when deprecating stuff, we'd do it like so:
>
> 1. Mark something as scheduled for deprecated in the documentation and the changelog.
>
> 2. Mark it as deprecated and give deprecated an informative message.
>
> 3. Remove the deprecated symbol.
>
> There would be no messages until #2. In any case, this is probably a bit long for a fairly simple question: is anyone opposed to my going and removing all of the "scheduled for deprecation" pragmas so that they aren't in the next release, given that pretty much everyone who mentions them doesn't like them?
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

Yes please.

On Mon, Oct 24, 2011 at 8:23 AM, Jesse Phillips <jesse.k.phillips at gmail.com> wrote:
> I would be for your proposal. Knowing that it will be deprecated is not too useful when you don't know where it is used.
>
> On Sat, Oct 22, 2011 at 3:17 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> Okay. From the looks of it, at same point relatively soon, we're going to have the ability to give deprecated a message, which will improve deprecated considerably, but we have not agreed on any changes to deprecated which would support "scheduled for deprecation." We have been using pragmas to add messages to some of the stuff that's been scheduled for deprecation, but that only works with templated stuff, and some people have been complaining about it, particularly since the messages don't (and can't) tell them _where_ in their code the soon to be deprecated stuff is being used. Given the complaints and the fact that we can't actually use messages unilaterally with stuff which has been scheduled for deprecation, at this point, I'm inclined to think that we'd be better off just removing the pragmas on stuff that's been scheduled for deprecation. Is anyone opposed to this?
>>
>> If not, then I'd like to make the changes ASAP so that they can make it into the next release. I don't think that anything else has been scheduled for deprecation since the last release, but since the messages have been causing complaints, I'd like to get the situation settled, and if we're not going to be improving deprecated to deal with "scheduled for deprecation" anytime soon, then I think that we should just drop the practice of using pragmas for it.
>>
>> I'd leave in the pragmas on the stuff which has already been deprecated until deprecated can take a message, but for the "scheduled for deprecation" stuff, I think that we should remove the pragmas, since they appear to be primarily annoying people.
>>
>> So, in the long run, when deprecating stuff, we'd do it like so:
>>
>> 1. Mark something as scheduled for deprecated in the documentation and the changelog.
>>
>> 2. Mark it as deprecated and give deprecated an informative message.
>>
>> 3. Remove the deprecated symbol.
>>
>> There would be no messages until #2. In any case, this is probably a bit long for a fairly simple question: is anyone opposed to my going and removing all of the "scheduled for deprecation" pragmas so that they aren't in the next release, given that pretty much everyone who mentions them doesn't like them?
>>
>> - Jonathan M Davis
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
>
>
> --
> Liberty means responsibility. That is why most men dread it.
> ? - George Bernard Shaw
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>