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




------- Comment #1 from bugzilla digitalmars.com  2007-09-05 01:28 -------
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                     |




------- Comment #2 from smjg iname.com  2007-09-05 17:32 -------
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


--- Comment #3 from yebblies <yebblies gmail.com> 2011-06-16 04:43:29 PDT ---
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


--- Comment #4 from bearophile_hugs eml.cc 2011-06-16 04:50:59 PDT ---
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



--- Comment #5 from yebblies <yebblies gmail.com> 2011-06-16 05:14:26 PDT ---
(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.

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



--- Comment #6 from bearophile_hugs eml.cc 2011-06-16 05:22:13 PDT ---

 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



--- Comment #7 from yebblies <yebblies gmail.com> 2011-06-16 05:39:11 PDT ---
(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.

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


--- Comment #8 from Stewart Gordon <smjg iname.com> 2011-06-16 05:56:48 PDT ---
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.

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



--- Comment #9 from yebblies <yebblies gmail.com> 2011-06-16 06:32:51 PDT ---
(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.

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



--- 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
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


--- 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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
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


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