http://d.puremagic.com/issues/show_bug.cgi?id=1449
--- Comment #17 from klickverbot <[email protected]> 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: -------
