Bug 1449 – deprecated methods are counted as interface implementation

class Foo : Bar { deprecated void foo() {} } interface Bar { void foo(); } compiles cleanly with "dmd -c deprecatedtest.d"

Deprecated methods issue an error if they are called, not if they are declared.

That's completely irrelevant. The point is that, because the implementing method is deprecated, the class effectively doesn't implement the interface it claims to.

This is INVALID, the compiler behaves according to spec. Open an enhancement request if you think the compiler should do something different.

Please yebblies, you are doing a good work, but be generally more careful before closing issues. If Lars Ivar Igesund isn't around now (this was from 2007!) to look at this bug report he may not open an enhancement request! Creating bug report is a lot of work, they often contain important usability insights even when they are "wrong". Some times it does less harm to keep them open than to close them by mistake.

(In reply to comment #4) > Please yebblies, you are doing a good work, but be generally more careful > before closing issues. If Lars Ivar Igesund isn't around now (this was from > 2007!) to look at this bug report he may not open an enhancement request! > Creating bug report is a lot of work, they often contain important usability > insights even when they are "wrong". Some times it does less harm to keep them > open than to close them by mistake. Bugzilla is not a sanctuary for ideas. It is a list of issues with the language to be fixed, and possible enhancements to be either incorporated into the language or rejected. Closing a bug report that is invalid does not do harm to anything, the information is still there, the marking is accurate, and the people who might want to propose something similar as a language change are notified (the reporter is emailed, and a notification is posted to the digitalmars.D.bugs list). I don't think anything you've said is a good reason to clutter up bugzilla by leaving an old, invalid bug report open. That being said, I am careful about closing issues. There is no valid bug anywhere in this report. As far as I know this is not a commonly reported complaint nor is there any proposal that would change this behavior. It's simply invalid.

> Closing a bug report that is invalid does not do harm to anything, the information is still there, I think that in practice you are wrong: with the amount of open bugs, a closed bugs becomes invisible.

(In reply to comment #6) > > Closing a bug report that is invalid does not do harm to anything, the > information is still there, > > I think that in practice you are wrong: with the amount of open bugs, a closed > bugs becomes invisible. An invalid bug that is closed SHOULD be invisible. If you think there's a valid enhancement in here, open a new bug for it. There is no way we should be keeping invalid bugs open because somebody may have a related enhancement request that they didn't put anywhere in a bug report that they filed four years ago.

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. (In reply to comment #5) > Bugzilla is not a sanctuary for ideas. It is a list of issues with the > language to be fixed, and possible enhancements to be either incorporated into > the language or rejected. How is this not an issue with the language to be fixed? If it isn't an issue with the language to be fixed, how is it not a possible enhancement to be either incorporated into the language or rejected? > That being said, I am careful about closing issues. There is no valid bug > anywhere in this report. As far as I know this is not a commonly reported > complaint Commonness of reporting is not a criterion for the validity of a bug. > nor is there any proposal that would change this behavior. It's > simply invalid. No it isn't. And even those that are invalid should, where it makes sense to do so, have their levels changed to "enhancement" rather than just closed.

(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: > 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? > (In reply to comment #5) > > Bugzilla is not a sanctuary for ideas. It is a list of issues with the > > language to be fixed, and possible enhancements to be either incorporated into > > the language or rejected. > > How is this not an issue with the language to be fixed? The compiler behaves as described in the spec. > If it isn't an issue with the language to be fixed, how is it not a possible > enhancement to be either incorporated into the language or rejected? What is the requested enhancement? Please, write one up. There isn't one anywhere in this report. > > > That being said, I am careful about closing issues. There is no valid bug > > anywhere in this report. As far as I know this is not a commonly reported > > complaint > > Commonness of reporting is not a criterion for the validity of a bug. No, but I find it a good metric for finding behavior that is bug prone or confusing, and might be worth considering an enhancement request for. > > > nor is there any proposal that would change this behavior. It's > > simply invalid. > > No it isn't. > > And even those that are invalid should, where it makes sense to do so, have > their levels changed to "enhancement" rather than just closed. I would have done that if it made sense to do so. The compiler works as described in the spec within the case in this report. Walter has clarified that this is intentional, and therefore not a bug. If you think the spec and the design of D are not what they should be, that is by definition an enhancement. So please, write one up.

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

(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?

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

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.

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

(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?

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

(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

*** This issue has been marked as a duplicate of issue 6760 ***