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?

On 07-11-2012 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?

Just fix the compiler behavior.

https://github.com/D-Programming-Language/phobos/pull/904#issuecomment-10038838

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

Le 07/11/2012 00:56, Walter Bright a écrit :
> 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 sound like a perfect use case for attribute.

On Tuesday, November 06, 2012 15:56:09 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?

And how would this interact with -d? It's one thing to give symbols attributes which can be examined at compile time. It's quite another to make it so that they don't compile without a specific compiler flag.

I also don't really get what we gain from this. The only thing that I'm aware of which is really up for debate at this point is whether deprecated should result in an error or a warning. We even have messages for it now.

Adding custom attributes which somehow indicate "scheduled for deprecation" or something like that might make sense, but what is beneficial abou removing deprecated itself from the language? How could that even work given that deprecated does more than simply tag the symbol with information?

- Jonathan M Davis

Walter Bright:

> Perhaps it could be done with a user defined attribute instead?

Maybe we need more ways to better attach some semantics to UDAs :-)

Bye,
bearophile

On 11/7/12 1:56 AM, 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?

I don't think that's possible. One would need a mechanism to hook into all calls to a function (adorned with a specific attribute) and emit the message during compilation. That is missing.

Andrei

On 11/6/2012 5:12 PM, Jonathan M Davis wrote:
> And how would this interact with -d? It's one thing to give symbols attributes
> which can be examined at compile time. It's quite another to make it so that
> they don't compile without a specific compiler flag.

The -version flag can be used to turn things on and off in user code.


> I also don't really get what we gain from this. The only thing that I'm aware
> of which is really up for debate at this point is whether deprecated should
> result in an error or a warning. We even have messages for it now.

The gain is in reducing the demand for constant language changes. It's similar to the ability to now do GC introspection entirely in the library, rather than changing the compiler.


> Adding custom attributes which somehow indicate "scheduled for deprecation" or
> something like that might make sense, but what is beneficial abou removing
> deprecated itself from the language? How could that even work given that
> deprecated does more than simply tag the symbol with information?

I didn't say remove it. I said deprecate it.

On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote:
> I don't think that's possible. One would need a mechanism to hook into all calls
> to a function (adorned with a specific attribute) and emit the message during
> compilation. That is missing.

It would be interesting to see where those pain points are, and whether a general "hook" mechanism for user plugins would be a good idea.

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

On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote:
> -- : 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

Or some other default (I don't really care), but there needs to be a switch to say "don't use anything but the bleeding edge valid code".

dw seems like a good "default" compromise, and the two others beeing user specified.