www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1449] New: deprecated methods are counted as interface implementation

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449

           Summary: deprecated methods are counted as interface
                    implementation
           Product: D
           Version: 1.020
          Platform: Other
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: larsivar igesund.net


class Foo : Bar {
    deprecated void foo() {}
}

interface Bar {
    void foo();
}

compiles cleanly with "dmd -c deprecatedtest.d"


-- 
Aug 29 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID





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


-- 
Sep 04 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |





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.


-- 
Sep 05 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |yebblies gmail.com
         Resolution|                            |INVALID



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449





 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449




 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449





 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


Stewart Gordon <smjg iname.com> changed:

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



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.


 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449





 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?

 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449




06:44:29 PDT ---


 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449






 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.
 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449





 
 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


klickverbot <code klickverbot.at> changed:

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



---
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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449





 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449




---


 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449




 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449




---

 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: -------
Jun 16 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1449


yebblies <yebblies gmail.com> changed:

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



*** 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: -------
Jan 30 2012