On Wednesday, November 07, 2012 08:03:54 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

It would be better if deprecated stuff warned by default and only errored if you ask it to. The problem is that as it is now, if you mark anything is deprecated, you instantly break all code using it without warning. The only way that anyone can know if you intended for something to be deprecated and get the chance to fix their code before it breaks is if you tell them in the documenation or changelog or whatnot, which doesn't tell them where in their code they're using it, and is frequently going to be outright ignored.

Certainly, from Phobos' perspective, the fact that deprecating something makes it so that it doesn't compile is a problem, because it means that as soon as we deprecate something, we break people's code (essentially without warning), and we don't want to do that. So, if we refuse to ever break people's code like that, we can't use deprecated.

It would be nice to have a two-tiered approach where something is soft deprecated (and therefore warns) or is hard deprecated (and therefore gives an error), but that's been rejected in the past due to the extra complication that it adds.

If we don't want to complicate the feature any further, then flags _could_ be used to control it, but then we'd probably need to make warn the default and have flags for making it an error or be ignored (or maybe even make it impossible to ignore, since it's a warning rather than an error). However, it would be bad if it were treated like a normal warning is and turned into an error with -w, because plenty of folks compile with -w, and so it would then once again become the case that deprecating anything would instantly break code without warning. As such, part of me wants to make it so that deprecated _never_ stops compilation, but you do bring up a good point that there are times that you need to (particularly where conditional compilation is concerned).

- Jonathan M Davis

Am 07.11.2012 03:55, schrieb Andrei Alexandrescu:
> 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

If that was there though, it would also be very close to being able to define things like @safe or @nothrow or @nogc as pure library functionality. This could offer some very interesting new static checking opportunities.

On 11/06/2012 10:03 PM, 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
>
>

I'm in favor of this; we can stop filling Phobos with "scheduled for deprecation," and just deprecate things. People using e.g. std.xml would get warnings but not have to refactor all their code at once.

NMS

On 2012-11-07 04:40, Walter Bright wrote:

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

I would assume that if a feature is getting deprecated it will be removed somewhere in the future, otherwise what's the reason for deprecating it?

-- 
/Jacob Carlborg

On 2012-11-07 04:41, Walter Bright wrote:

> 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.

I think that with UDA in combination with AST macros it could work.

@deprecated("don't use this feature any more") int foo (int a) { return a + 3; }

In this case @deprecated would be a macro annotation/attribute or a declaration macro or what to call it. The macro would receive the AST of the declared language element, in this case the function. The AST return by the macro would be inserted instead of the declared function "foo".

The @deprecated macro would return an AST for the following code:

int foo (int a)
{
    static assert(false, "don't use this feature any more"); // use this for error
    // pragma(msg, "don't use this feature any more"); // use this for warning
    return a + 3;
}

Have a look at Scala macro annotations:

http://scalamacros.org/future.html

-- 
/Jacob Carlborg

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

I think it's a bit too soon to start replacing language features with UDA.

-- 
/Jacob Carlborg

[OT] deprecated attribute is yet not correctly implemented by the compiler.

http://d.puremagic.com/issues/show_bug.cgi?id=7619

Kenji Hara

2012/11/7 Walter Bright <newshound2@digitalmars.com>:
> 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 Wednesday, 7 November 2012 at 02:55:38 UTC, 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.

The attribute can be declared in library, but processed by the compiler - that's how C# works.
See
http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx
http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx

Le 07/11/2012 04:41, Walter Bright a écrit :
> 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.
>

The hook should be in D and CTFEable. This require an API provided in druntime or phobos. This is heavy work, but would definitively worth it.

Le 07/11/2012 11:42, Jacob Carlborg a écrit :
> On 2012-11-07 04:41, Walter Bright wrote:
>
>> 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.
>
> I think that with UDA in combination with AST macros it could work.
>
> @deprecated("don't use this feature any more") int foo (int a) { return
> a + 3; }
>
> In this case @deprecated would be a macro annotation/attribute or a
> declaration macro or what to call it. The macro would receive the AST of
> the declared language element, in this case the function. The AST return
> by the macro would be inserted instead of the declared function "foo".
>
> The @deprecated macro would return an AST for the following code:
>
> int foo (int a)
> {
> static assert(false, "don't use this feature any more"); // use this for
> error
> // pragma(msg, "don't use this feature any more"); // use this for warning
> return a + 3;
> }
>
> Have a look at Scala macro annotations:
>
> http://scalamacros.org/future.html
>

This is nice, but lack the possible to explore the internal of the function and to surgery in it :D

Still a step forward.