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

           Summary: [Tracker] Forward reference bugs and other order-of-
                    declaration issues
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: smjg@iname.com
        ReportedBy: smjg@iname.com
 BugsThisDependsOn: 52,102,104,190,235,275,339


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.


-- 

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


dawid.ciezarkiewicz@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawid.ciezarkiewicz@gmail.co
                   |                            |m
               Flag|                            |d1.0blocker?




------- Comment #1 from dawid.ciezarkiewicz@gmail.com  2006-09-19 12:00 -------
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.


-- 

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


moritzwarning@web.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |moritzwarning@web.de




------- Comment #2 from moritzwarning@web.de  2007-10-21 18:18 -------
I hope this collection of bugs will be fixed soon.
I already invested too much time finding out about it (the hard way).


-- 

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





------- Comment #3 from jarrett.billingsley@gmail.com  2007-11-13 14:03 -------
(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.


-- 

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





------- Comment #4 from smjg@iname.com  2007-11-13 17:09 -------
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!


-- 

<d-bugmail@puremagic.com> wrote in message news:fhdarg$104f$1@digitalmars.com...
> http://d.puremagic.com/issues/show_bug.cgi?id=340

> ------- Comment #4 from smjg@iname.com  2007-11-13 17:09 -------
> 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!

I did.  1667.  I'm just disgusted that a bugs this old and this numerous fly under the radar.

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





------- Comment #5 from smjg@iname.com  2008-11-13 20:31 -------
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?


-- 

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





------- Comment #6 from jarrett.billingsley@gmail.com  2008-11-13 21:30 -------
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.)


-- 

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





------- Comment #7 from smjg@iname.com  2008-11-14 06:20 -------
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.)


-- 

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


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au




--- Comment #8 from Don <clugdbug@yahoo.com.au>  2009-07-22 04:35:56 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------