On 11/8/2012 12:13 AM, Don Clugston wrote:
> That *cannot* fix the problem.
> The problem is not with the deprecated attribute at all, it's with the command
> line switches.

Of interest:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html

Looks like another D feature moving into C++!

On 11/9/12, Walter Bright <newshound2@digitalmars.com> wrote:
> On 11/8/2012 12:13 AM, Don Clugston wrote:
>> That *cannot* fix the problem.
>> The problem is not with the deprecated attribute at all, it's with the
>> command
>> line switches.
>
> Of interest:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
>
> Looks like another D feature moving into C++!
>

They terk err jerbs!!

On Friday, November 09, 2012 00:49:19 Walter Bright wrote:
> On 11/8/2012 12:13 AM, Don Clugston wrote:
> > That *cannot* fix the problem.
> > The problem is not with the deprecated attribute at all, it's with the
> > command line switches.
> 
> Of interest:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
> 
> Looks like another D feature moving into C++!

One major difference in what they're describing vs what we have is that for us, deprecated immediately triggers an error, whereas for them, it's a warning by default. I think that we'd to well to change to that scheme to match theirs (though have whether it's treated as an error be kept separate from -w so that normal warnings because many people compile with it normally). That way, by default, deprecating something doesn't break people's code but rather simply encourages them to change it, and their code won't be broken until the symbol is actually remove from the library or they choose to compile with -dw (or whatever we name the switch that makes using deprecated symbols an error).

As it stands, if we don't want to break anyone's code, we can't really use deprecated, whereas if it were changed to warn by default, we _could_ use it where appropriate and thereby encourage people to change their code but not break anyone's code. It also avoids the problem of people not being aware that something is going to be deprecated before their code stops compiling due to it being deprecated or removed, since right now, the only way to know if something is going to be deprecated is to read the changelog or documentation, which many people won't read.

- Jonathan M Davis

On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
> On 11/8/2012 12:13 AM, Don Clugston wrote:
>> That *cannot* fix the problem.
>> The problem is not with the deprecated attribute at all, it's with the command
>> line switches.
>
> Of interest:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
>
> Looks like another D feature moving into C++!

I'd say, gcc's attribute system is used better than in D.
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes
They use attributes for const, pure, nothrow, dllimport, while D uses keywords.

On 09-11-2012 19:06, Kagamin wrote:
> On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
>> On 11/8/2012 12:13 AM, Don Clugston wrote:
>>> That *cannot* fix the problem.
>>> The problem is not with the deprecated attribute at all, it's with
>>> the command
>>> line switches.
>>
>> Of interest:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
>>
>> Looks like another D feature moving into C++!
>
> I'd say, gcc's attribute system is used better than in D.
> http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#Function-Attributes
>
> They use attributes for const, pure, nothrow, dllimport, while D uses
> keywords.

And they are tedious as hell to type.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
> On 07/11/12 00:56, Walter Bright wrote:
>> I know there's been some long term unhappiness about the deprecated
>> attribute - it's all-or-nothing approach, poor messages, etc. Each
>> change in it changes the language and the compiler.
>>
>> Perhaps it could be done with a user defined attribute instead?
>>
>> Anyone want to take on the challenge?
>
> That *cannot* fix the problem.
> The problem is not with the deprecated attribute at all, it's with the command line switches.

Exactly, deprecated is one of those features that *needs* to be
in the compiler, at least part of it. Because is not only about
the deprecated attribute for user symbols, there are also
deprecated constructs in the language, that only the compiler can
detect and can emit messages for.

Having deprecated as a core part of the language is not an
option, is the only way to do it right, so why don't we just fix
it in the compiler then? Adding the deprecated("message") syntax
was a huge step forward. Now we just need an option to emit
deprecations as warnings and that's it. It's already there, you
just have to merge it :)

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

On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote:
> On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
>> I know there's been some long term unhappiness about the deprecated attribute - it's all-or-nothing approach, poor messages, etc. Each change in it changes the language and the compiler.
>
> I *just* had a conversation about this, but there *needs* to be a way to to tell the compiler: "don't use deprecated stuff": If it merely issues a warning, then you'll end up calling deprecated code, because traits will answer positively to something that is actually deprecated:
>
> For example if a range has "deprecated opIndex", and you try a search on that range, the implementation will take the RA road...
>
> I had proposed a "three state -d":
> -- : Deprecated stuff just can't be used
> -d : You can use deprecated stuff, but you get no warning
> -dw : You can use deprecated stuff, and are served with a warning

BTW, I already implemented that and is available as a pull request (I just called the option -di to follow the naming of -wi).
https://github.com/D-Programming-Language/dmd/pull/1185

This pull request is available since July 2011 (was pull #248 back then), and I'm trying to convince Walter to merge it since then without any success. I'm really glad this finally came up here, maybe he finally understand the importance of having an usable deprecated implementation :)

BTW, I think the default should be to have deprecations as warnings and not the other way around, but since I at least have the option to make them warnings, I'm fine.

On 11-11-2012 14:18, Leandro Lucarella wrote:
> On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote:
>> On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
>>> I know there's been some long term unhappiness about the deprecated
>>> attribute - it's all-or-nothing approach, poor messages, etc. Each
>>> change in it changes the language and the compiler.
>>
>> I *just* had a conversation about this, but there *needs* to be a way
>> to to tell the compiler: "don't use deprecated stuff": If it merely
>> issues a warning, then you'll end up calling deprecated code, because
>> traits will answer positively to something that is actually deprecated:
>>
>> For example if a range has "deprecated opIndex", and you try a search
>> on that range, the implementation will take the RA road...
>>
>> I had proposed a "three state -d":
>> -- : Deprecated stuff just can't be used
>> -d : You can use deprecated stuff, but you get no warning
>> -dw : You can use deprecated stuff, and are served with a warning
>
> BTW, I already implemented that and is available as a pull request (I
> just called the option -di to follow the naming of -wi).
> https://github.com/D-Programming-Language/dmd/pull/1185
>
> This pull request is available since July 2011 (was pull #248 back
> then), and I'm trying to convince Walter to merge it since then without
> any success. I'm really glad this finally came up here, maybe he finally
> understand the importance of having an usable deprecated implementation :)
>
> BTW, I think the default should be to have deprecations as warnings and
> not the other way around, but since I at least have the option to make
> them warnings, I'm fine.

Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries because it can break arbitrary build systems out there.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 11-11-2012 14:09, Leandro Lucarella wrote:
> On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
>> On 07/11/12 00:56, Walter Bright wrote:
>>> I know there's been some long term unhappiness about the deprecated
>>> attribute - it's all-or-nothing approach, poor messages, etc. Each
>>> change in it changes the language and the compiler.
>>>
>>> Perhaps it could be done with a user defined attribute instead?
>>>
>>> Anyone want to take on the challenge?
>>
>> That *cannot* fix the problem.
>> The problem is not with the deprecated attribute at all, it's with the
>> command line switches.
>
> Exactly, deprecated is one of those features that *needs* to be
> in the compiler, at least part of it. Because is not only about
> the deprecated attribute for user symbols, there are also
> deprecated constructs in the language, that only the compiler can
> detect and can emit messages for.
>
> Having deprecated as a core part of the language is not an
> option, is the only way to do it right, so why don't we just fix
> it in the compiler then? Adding the deprecated("message") syntax
> was a huge step forward. Now we just need an option to emit
> deprecations as warnings and that's it. It's already there, you
> just have to merge it :)
>
> https://github.com/D-Programming-Language/dmd/pull/1185

I'm against that pull request. Not because I think it isn't useful, but because I think it doesn't fix the problem.

Usage of deprecated symbol(s) should be a warning by default and the new option should be used to turn that into an error; not the other way around.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Sunday, 11 November 2012 at 13:59:59 UTC, Alex Rønne Petersen wrote:
> Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries

+1. Or even plus a whole lot more, if I had multiple votes.

David