www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 340] New: [Tracker] Forward reference bugs and other order-of-declaration issues

reply d-bugmail puremagic.com writes:
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.


-- 
Sep 10 2006
next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Sep 19 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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).


-- 
Oct 21 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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. --
Nov 13 2007
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
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!


-- 
Nov 13 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
<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.
Nov 13 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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?


-- 
Nov 13 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.)


-- 
Nov 13 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.) --
Nov 14 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario gmx.de


--- Comment #9 from Rainer Schuetze <r.sagitario gmx.de> 2009-09-16 01:00:07
PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340



--- Comment #10 from Don <clugdbug yahoo.com.au> 2009-09-16 01:13:39 PDT ---
(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! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340



--- Comment #11 from Stewart Gordon <smjg iname.com> 2009-09-16 01:53:01 PDT ---
(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.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340


罗勇刚 <yonggangluo hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yonggangluo hotmail.com


--- Comment #12 from 罗勇刚 <yonggangluo hotmail.com> 2009-11-06 03:06:31
PST ---
Maybe it's toooooo hard to fix it up!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340



--- Comment #13 from Stewart Gordon <smjg iname.com> 2009-11-07 08:35:19 PST ---
(In reply to comment #12)
 Maybe it's toooooo hard to fix it up!

To fix what up? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 07 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340



--- Comment #14 from 罗勇刚 <yonggangluo hotmail.com> 2009-11-11 05:26:17
PST ---
(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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 11 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=340



--- Comment #15 from Don <clugdbug yahoo.com.au> 2010-12-08 23:57:58 PST ---
Once again, can people PLEASE STOP VOTING FOR THIS BUG!

This is *not* a bug. It's a tracker.

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