[Issue 1449] deprecated methods are counted as interface implementation

[d-bugmail at puremagic.com]

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



--- Comment #17 from klickverbot <code at 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: -------