Bug 340 – [Tracker] Forward reference bugs and other order-of-declaration issues

A design principle of D is that the order of declarations at module level or class level is irrelevant. Here's just one statement to this effect: [Features to Drop] "Forward declarations. C compilers semantically only know about what has lexically preceded the current state. C++ extends this a little, in that class members can rely on forward referenced class members. D takes this to its logical conclusion, forward declarations are no longer necessary at the module level. Functions can be defined in a natural order rather than the typical inside-out order commonly used in C programs to avoid writing forward declarations." (There ought to be more, but I can't seem to find them at the moment.) As such, there should be no errors reported by the compiler caused by trying to use a symbol before it's defined. Of course it makes sense that a variable can't be used within a function before it's declared, with functions being sequential in nature. But otherwise, the compiler should accept forward references without any trouble. There are two documented instances for which forward references fail, namely nested functions within a function and autotype declarations. Otherwise, any failures of a D compiler to get over the fact that the use of a symbol lexically precedes its declaration in a module, class, etc. are bugs. While we're at it, forward reference bugs are part of a more general class of issues whereby the compiler treats code differently depending on the lexical order of declarations. These can include not only valid code failing to compile, but also instances where the code compiles either way but behaves differently. This is a tracker for bugs of this nature - bugs whereby code containing forward references fails to compile correctly, and anywhere else where the order of declarations influences compiler behaviour in a way that should not be happening. Getting the phrase "forward referenced" out of the compiler's repertoire of error messages (by actually fixing the bugs, obviously, not by rewording the error) would certainly be a step forward.

This is the only problem i'm aware of so big that it forces to stop using D in bigger and really object oriented projects. The day when it will be fixed will be the biggest Internet event that I'm waiting for.

I hope this collection of bugs will be fixed soon. I already invested too much time finding out about it (the hard way).

(In reply to comment #0) > A design principle of D is that the order of declarations at module level or > class level is irrelevant. > > Here's just one statement to this effect: > > [Features to Drop] > "Forward declarations. C compilers semantically only know about what has > lexically preceded the current state. C++ extends this a little, in that class > members can rely on forward referenced class members. D takes this to its > logical conclusion, forward declarations are no longer necessary at the module > level. Functions can be defined in a natural order rather than the typical > inside-out order commonly used in C programs to avoid writing forward > declarations." > > (There ought to be more, but I can't seem to find them at the moment.) > > As such, there should be no errors reported by the compiler caused by trying to > use a symbol before it's defined. Of course it makes sense that a variable > can't be used within a function before it's declared, with functions being > sequential in nature. But otherwise, the compiler should accept forward > references without any trouble. > > There are two documented instances for which forward references fail, namely > nested functions within a function and autotype declarations. Otherwise, any > failures of a D compiler to get over the fact that the use of a symbol > lexically precedes its declaration in a module, class, etc. are bugs. > > While we're at it, forward reference bugs are part of a more general class of > issues whereby the compiler treats code differently depending on the lexical > order of declarations. These can include not only valid code failing to > compile, but also instances where the code compiles either way but behaves > differently. > > This is a tracker for bugs of this nature - bugs whereby code containing > forward references fails to compile correctly, and anywhere else where the > order of declarations influences compiler behaviour in a way that should not be > happening. > > Getting the phrase "forward referenced" out of the compiler's repertoire of > error messages (by actually fixing the bugs, obviously, not by rewording the > error) would certainly be a step forward. > RRRRGH RRRRRRRRRRRRRRRRRRRRRRRR FIX FORWARD REFERENCE ERRORS NOW .. I've just run into ANOTHER forward reference error that is absolutely un-work-around-able. These are the only bugs in the DMDFE that really cause an issue for me. It's REALLY pissing me off.

There's no need for "me too" messages here, let alone of the stereotypical kind that quotes the whole original message. If you've found a forward reference bug that isn't already filed, then file it!

There have been a few bugs listed here that aren't forward reference issues as such, i.e. don't result from something being forward referenced, but nonetheless have "forward declaration" or "forward reference" in the error message generated. Some of these are circular import problems, which tend to be closely related to forward reference problems. And besides, they do tend to depend on the order of something, be it import declarations or modules given on the command line. So maybe there's an excuse for tracking these here. But some don't fall under this category, such as issue 1667. No circular import, no forward reference, and not an order-of-declaration issue as such either - just the phrase "forward declaration" in the compiler error. Do we think it's desirable to have such issues as this as dependencies of this one?

I think if you want to define forward references in the restricted classical definition of "lexical precedence," then bugs like 1667 would not be covered by this one. But it would be a pointless distinction between lexical forward references and semantic ones. Any time the compiler outputs an error about forward references/declarations, it means it's not walking the symbol dependency graph in the correct order. That the compiler sometimes resolves dependencies lexically and sometimes not is irrelevant to the fact that it is resolving them incorrectly. (funny - your last two comments were posted one year apart to the day.)

I'm not sure what you mean by a semantic forward reference, but I guess you're right about the basic essence of the bug. > (funny - your last two comments were posted one year apart to the > day.) That would be true if only I had been in UTC-3 or behind at the time. But an astute observation in any case. (See also issue 1047.)

Please don't vote for this. It is a tracker, not a bug. Please vote for the individual forward reference bug(s) which you consider to be most important.

I created some patches dealing with about 5 issues that currently leave only 12 bugs unfixed (of about 40 reports in bugzilla that deal with forward references and circular import problems - I could add some more dependencies to this tracker). But where in bugzilla should I attach the patches? Some bugs might be fixed with only part of the changes, while other rely on these. I don't want to duplicate patches in different bug reports. Is this tracker bug the right place? It seems it is not meant to hold patches.

(In reply to comment #9) > I created some patches dealing with about 5 issues that currently leave only 12 > bugs unfixed (of about 40 reports in bugzilla that deal with forward references > and circular import problems - I could add some more dependencies to this > tracker). > > But where in bugzilla should I attach the patches? Some bugs might be fixed > with only part of the changes, while other rely on these. I don't want to > duplicate patches in different bug reports. Is this tracker bug the right > place? > It seems it is not meant to hold patches. No, nothing should go in this tracker. It's compensating for the lack of a 'forward-reference' keyword. Personally I'm not convinced that these tracker bugs are helpful. Attach the patches to the individual bugs. If one patch fixes two bugs, just put it in one of them, and in the other, add a comment 'the patch for bug XXX also fixes this'. The add the 'patch' keyword to both bug reports. Looking forward to see what you've got!

(In reply to comment #10) > No, nothing should go in this tracker. It's compensating for the lack of a > 'forward-reference' keyword. Personally I'm not convinced that these tracker > bugs are helpful. The way I see it, it's supplementing keywords (and indeed products/components) by providing a means of grouping together issue with a common theme or towards a common objective. Our keywords, OTOH, mainly different characteristics a bug may have. OK, so there are other ways of using both trackers and keywords. Look on http://bugzilla.mozilla.org/ at how extensively they're used. (There, incidentally, is a keyword "meta" indicating tracker bugs.)

Maybe it's toooooo hard to fix it up!

(In reply to comment #12) > Maybe it's toooooo hard to fix it up! To fix what up?

(In reply to comment #13) > (In reply to comment #12) > > Maybe it's toooooo hard to fix it up! > > To fix what up? enum forward referenced hell.

Once again, can people PLEASE STOP VOTING FOR THIS BUG! This is *not* a bug. It's a tracker.

There are only 5 bugs left. Can this tracker be closed? If not, when will it be closed?

I'm closing this.

I've noticed this meta issue when I used to fix bugs and I think it was only useful to show that there WAS a big problem in the compiler. There are more that are not listed here and I think there will always be a few cases that are not fixable. Out of order declarations, lazy semantic and multi passes will ALWAYS have problems although in most of the cases this gives great power and works fine. People just gotta admit that not everything can work. The little pity is that we can't formally define what will not work.