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



--- Comment #10 from Lars Ivar Igesund <larsivar@igesund.net> 2011-06-16 06:44:29 PDT ---
(In reply to comment #9)

> To quote the spec:
> > It is often necessary to deprecate a feature in a library, yet retain it for
> > backwards compatibility. Such declarations can be marked as deprecated, which > means that the compiler can be set to produce an error if any code refers to
> > deprecated declarations
> 
> Where is the code referring to a deprecated declaration?

It does so implicitly.

If you have

Bar b = new Foo;

and do

b.foo();

the compiler will not be able to catch it, as it cannot know whether an arbitrary Bar instance actually is an instance of Foo. So at runtime, a deprecated function will be called, or attempted to be called.

The spec probably does not cover this particular usecase, but it seems to me that it is worth a warning. It just doesn't make sense to have an implementation be deprecated, when the same function in the interface is not.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #11 from Stewart Gordon <smjg@iname.com> 2011-06-16 06:45:09 PDT ---
(In reply to comment #9)
> (In reply to comment #8)
>> I agree with Bearophile.  Moreover, as I see it, a hole in the deprecation system constitutes a bug, just as most of us seem to agree that a hole in the const/immutable system (of which there are many) constitutes a bug.
>> 
> 
> To quote the spec:

The spec is in itself a place where bugs may exist.  Indeed, it's where many of the bugs in const/immutable are or have been.

>> It is often necessary to deprecate a feature in a library, yet retain it for backwards compatibility. Such declarations can be marked as deprecated, which > means that the compiler can be set to produce an error if any code refers to deprecated declarations
> 
> Where is the code referring to a deprecated declaration?

class Foo : Bar {
          ^^^^^
It's an indirect reference, but it's still essentially there.

(In reply to comment #9)
> Walter has clarified that this is intentional, and therefore not a bug.

Where and how?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #12 from yebblies <yebblies@gmail.com> 2011-06-16 07:22:09 PDT ---
(In reply to comment #10)
> 
> It does so implicitly.
> 
> If you have
> 
> Bar b = new Foo;
> 
> and do
> 
> b.foo();
> 
> the compiler will not be able to catch it, as it cannot know whether an arbitrary Bar instance actually is an instance of Foo. So at runtime, a deprecated function will be called, or attempted to be called.
> 
> The spec probably does not cover this particular usecase, but it seems to me that it is worth a warning. It just doesn't make sense to have an implementation be deprecated, when the same function in the interface is not.

I agree.  I think it should be an error to override a non-deprecated function with a deprecated one.  It should probably be an error to override a deprecated function with a non-deprecated one too.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


klickverbot <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at


--- Comment #13 from klickverbot <code@klickverbot.at> 2011-06-16 07:56:40 PDT ---
What do you think about adding something like this to the spec? »If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.«

This would make the use case of »deprecated« clearer, and issues like the above would be definitely bugs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #14 from yebblies <yebblies@gmail.com> 2011-06-16 08:17:10 PDT ---
(In reply to comment #13)
> What do you think about adding something like this to the spec? »If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.«
> 
> This would make the use case of »deprecated« clearer, and issues like the above would be definitely bugs.

I've always assumed that to be the case, and it should probably be added to the spec, but I don't believe it has any bearing on possible accepts-invalid bugs - they compile anyway as the attribute is effectively ignored.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #15 from klickverbot <code@klickverbot.at> 2011-06-16 08:44:21 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > What do you think about adding something like this to the spec? »If a program which includes deprecated declarations compiles without any related errors, it can be assumed to behave exactly the same if these declarations are completely removed from the source.«
> > 
> > This would make the use case of »deprecated« clearer, and issues like the above would be definitely bugs.
> 
> I've always assumed that to be the case, and it should probably be added to the spec, but I don't believe it has any bearing on possible accepts-invalid bugs - they compile anyway as the attribute is effectively ignored.

If that was stated explicitly in the spec, there is no way this bug could possibly be INVALID, as removing the declaration of foo() in the original example obviously breaks the build, even though it builds fine without »-d« being specified at the command line. Or am I misunderstanding you?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #16 from yebblies <yebblies@gmail.com> 2011-06-16 09:02:40 PDT ---
> If that was stated explicitly in the spec, there is no way this bug could possibly be INVALID, as removing the declaration of foo() in the original example obviously breaks the build, even though it builds fine without »-d« being specified at the command line. Or am I misunderstanding you?

Sorry!  I misread that as 'if the deprecated attribute is removed'.

That would definitely make this a bug, but I don't think it's possible.

Consider:

---

module a;

deprecated
extern extern(C) func() {}

---

module b;
import a;

extern extern(C) func();

void main()
{
   func();
}

---

Adding/removing members can also change instance sizes, vtable layouts etc, and that's without messing around with static if.

The current definition keeps it simple and achievable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #17 from klickverbot <code@klickverbot.at> 2011-06-16 09:32:19 PDT ---
(In reply to comment #16)
> > If that was stated explicitly in the spec, there is no way this bug could possibly be INVALID, as removing the declaration of foo() in the original example obviously breaks the build, even though it builds fine without »-d« being specified at the command line. Or am I misunderstanding you?
> 
> Sorry!  I misread that as 'if the deprecated attribute is removed'.
> 
> That would definitely make this a bug, but I don't think it's possible. […]

I wouldn't regard your example as a problem, because by specifying an »extern« declaration, you are assuring the compiler as the author of »module b« that you will take care of making sure that the function is actually available during linking. The modules a and b are two completely separate entities in your example which just happen to be linked together – the »import a« is not even needed.

vtable layouts and class instance sizes are also beyond the scope what »deprecated« as a language-level can possibly provide, but you are right, there _are_ some cases where removing a deprecated declaration could break language guarantees, e.g. for struct members.

Regardless, I don't quite see how the »current definition keeps it simple and achievable« – as far as I know, there doesn't even exist a precise definition of »deprecated« right now. All I could find in the spec is the related section on the »Attributes« page ([1]), and »produce an error if any code refers to deprecated declarations« is about as vague as it gets (as confirmed by the fact that we're having this discussion at all).

I agree that the wording in my above comment was not quite ideal, but I didn't think too much about it, as it was only intended as a quick suggestion – do you have ideas on how to state this better? Also, don't forget that what I informally described is actually the very raison d'être of »deprecated«: annotate pieces of your API which you are going to remove with it, so clients can see what will break when it'll actually be gone, but can still choose to stick with the current state for a limited amount of time by using the -d flag. As [2] puts it: »This [the deprecated attribute] will make it easy for maintenance programmers to identify any dependence on deprecated features.«


[1] http://www.d-programming-language.org/attribute.html#deprecated [2] http://www.d-programming-language.org/overview.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE


--- Comment #18 from yebblies <yebblies@gmail.com> 2012-01-31 18:52:51 EST ---
*** This issue has been marked as a duplicate of issue 6760 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------