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