View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2012
deprecate deprecated?
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?
November 06, 2012
Re: deprecate deprecated?
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
November 07, 2012
Re: deprecate deprecated?
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.
November 07, 2012
Re: deprecate deprecated?
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
November 07, 2012
Re: deprecate deprecated?
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
November 07, 2012
Re: deprecate deprecated?
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
November 07, 2012
Re: deprecate deprecated?
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.
November 07, 2012
Re: deprecate deprecated?
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.
November 07, 2012
Re: deprecate deprecated?
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
November 07, 2012
Re: deprecate deprecated?
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home