At the conference, I was asked in various ways how bug fixes and
improvements are prioritized, given that so much needs to be done.
The short answer is, it's ad hoc. The longer answer is I have some vague
notion of whatever bubbles to the top of a cost/benefit analysis.
The cost is how much work it is to implement plus how disruptive the
change will be to others. That means that trivial issues with little
benefit can get fixed quickly. An example of that would be something
like a spelling error or an obvious one liner fix.
For more complex issues, I have to look at how much benefit will it
produce. For example, a while back Don Clugston showed me that if
certain improvements were made to constant folding of string literals
were done, it would open the door to a whole new *class* of template
metaprogramming capability. This made it quite a huge benefit, and so it
bubbled up to the surface.
I also pay a lot more attention to issues people have that are blocking
work they are currently engaged in, than to issues of "it would be nice
to do this for other (unspecified) people." In other words, if there's a
current, real live use for a change, and no reasonable workaround, it's
a higher benefit for the cost.
Of course, sometimes it's leavened by just whatever catches interest du
jour <g>.

I also pay a lot more attention to issues people have that are blocking
work they are currently engaged in, than to issues of "it would be nice to
do this for other (unspecified) people." In other words, if there's a
current, real live use for a change, and no reasonable workaround, it's a
higher benefit for the cost.

Would forward reference issues fit that description? I think they do. See
bugzilla 102, 282, 912, and probably others.

I also pay a lot more attention to issues people have that are blocking
work they are currently engaged in, than to issues of "it would be nice to
do this for other (unspecified) people." In other words, if there's a
current, real live use for a change, and no reasonable workaround, it's a
higher benefit for the cost.

Would forward reference issues fit that description? I think they do. See
bugzilla 102, 282, 912, and probably others.

I also pay a lot more attention to issues people have that are
blocking work they are currently engaged in, than to issues of "it
would be nice to do this for other (unspecified) people." In other
words, if there's a current, real live use for a change, and no
reasonable workaround, it's a higher benefit for the cost.

Would forward reference issues fit that description? I think they
do. See bugzilla 102, 282, 912, and probably others.

The problem is, forward references also have a high cost to fixing.

So you'll kick forward this problem, while not letting us kick forward
declarations? <g>

They also have a high benefit: the compiler will no longer give errors (that
are impossible to workaround without serious redeisgns) on otherwise valid
code.
Furthermore, delaying issues that are difficult to fix means they will never
be fixed, at least not on any reasonable timescale. You know that with all
the new features you're going to be introducing that there will be tons of
bugs, probably lots of little easy ones. Keep squashing all the little
ones, though, and the big ones will just fester.
Another one that comes to mind is broken selective/renamed import privacy
(bugzilla 313/314). These are not minor issues, and if they take a lot of
time to fix -- so be it. I'd be happy to wait another couple of months for
all the cool new D2 features.

They also have a high benefit: the compiler will no longer give errors (that
are impossible to workaround without serious redeisgns) on otherwise valid
code.
Furthermore, delaying issues that are difficult to fix means they will never
be fixed, at least not on any reasonable timescale. You know that with all
the new features you're going to be introducing that there will be tons of
bugs, probably lots of little easy ones. Keep squashing all the little
ones, though, and the big ones will just fester.
Another one that comes to mind is broken selective/renamed import privacy
(bugzilla 313/314).

I hate those import bugs too, but are they really preventing anyone from
getting work done? It's not hard to work around usually.
--bb

They also have a high benefit: the compiler will no longer give errors (that
are impossible to workaround without serious redeisgns) on otherwise valid
code.
Furthermore, delaying issues that are difficult to fix means they will never
be fixed, at least not on any reasonable timescale. You know that with all
the new features you're going to be introducing that there will be tons of
bugs, probably lots of little easy ones. Keep squashing all the little
ones, though, and the big ones will just fester.
Another one that comes to mind is broken selective/renamed import privacy
(bugzilla 313/314).

I hate those import bugs too, but are they really preventing anyone from
getting work done? It's not hard to work around usually.

It becomes a real problem when porting code from say, C, because then
you don't want to reorganize the whole thing to avoid forward references
errors. If you're starting from scratch you can usually fix the
problems with some amount of trial and error, but if you're starting
with a couple of dozens of files ported from another language, it's a
lot harder.
The problem is that it's very hard to figure out what exactly causes
these errors, so fixing them can take a lot of time. You don't know
exactly what causes them, and you don't know exactly why it works if you
manage to fix them. It's just no fun.
To make matters worse, dmd 1.018 introduced a new forward reference
error into one of my projects. For now, I've just documented that you
need to use dmd 1.017 or older to compile it. Without a simple test
case, reporting it in the bugzilla will only get me replies the likes of
'dude, please post a minimal test case, or nothing will happen'. Making
such a test case could take me hours, and if it leads to the bug
(regression, even) getting fixed, it's still just the tip of the iceberg
when it comes to forward reference errors.
This kind of seemingly random errors have a really high pain-in-the-ass
factor. Please make them go away. Or at least document the known bugs
and their workarounds.

They also have a high benefit: the compiler will no longer give
errors (that are impossible to workaround without serious redeisgns)
on otherwise valid code.
Furthermore, delaying issues that are difficult to fix means they
will never be fixed, at least not on any reasonable timescale. You
know that with all the new features you're going to be introducing
that there will be tons of bugs, probably lots of little easy ones.
Keep squashing all the little ones, though, and the big ones will
just fester.
Another one that comes to mind is broken selective/renamed import
privacy (bugzilla 313/314).

I hate those import bugs too, but are they really preventing anyone
from getting work done? It's not hard to work around usually.

It becomes a real problem when porting code from say, C, because then
you don't want to reorganize the whole thing to avoid forward references
errors. If you're starting from scratch you can usually fix the
problems with some amount of trial and error, but if you're starting
with a couple of dozens of files ported from another language, it's a
lot harder.
The problem is that it's very hard to figure out what exactly causes
these errors, so fixing them can take a lot of time. You don't know
exactly what causes them, and you don't know exactly why it works if you
manage to fix them. It's just no fun.
To make matters worse, dmd 1.018 introduced a new forward reference
error into one of my projects. For now, I've just documented that you
need to use dmd 1.017 or older to compile it. Without a simple test
case, reporting it in the bugzilla will only get me replies the likes of
'dude, please post a minimal test case, or nothing will happen'. Making
such a test case could take me hours, and if it leads to the bug
(regression, even) getting fixed, it's still just the tip of the iceberg
when it comes to forward reference errors.
This kind of seemingly random errors have a really high pain-in-the-ass
factor. Please make them go away. Or at least document the known bugs
and their workarounds.

Oh yeh, I'm totally in agreement that the forward referencing errors are
bad and need fixing. I was only questioning whether the import issues
(313/314) were also in the same category of seriousness. The errors
generated because of those issues would generally be pretty easy to work
around I would think, even if they do make a mockery of module
encapsulation.
--bb

They also have a high benefit: the compiler will no longer give errors (that
are impossible to workaround without serious redeisgns) on otherwise valid
code.
Furthermore, delaying issues that are difficult to fix means they will never
be fixed, at least not on any reasonable timescale. You know that with all
the new features you're going to be introducing that there will be tons of
bugs, probably lots of little easy ones. Keep squashing all the little
ones, though, and the big ones will just fester.
Another one that comes to mind is broken selective/renamed import privacy
(bugzilla 313/314). These are not minor issues, and if they take a lot of
time to fix -- so be it. I'd be happy to wait another couple of months for
all the cool new D2 features.

I also pay a lot more attention to issues people have that are blocking
work they are currently engaged in, than to issues of "it would be nice
to do this for other (unspecified) people." In other words, if there's a
current, real live use for a change, and no reasonable workaround, it's a
higher benefit for the cost.

Would forward reference issues fit that description? I think they do.
See bugzilla 102, 282, 912, and probably others.

Why not just see 340, rather than singling out a few (one of which is a
duplicate of another anyway)? Moreover, is 282 really a forward reference
issue?
Stewart.

Why not just see 340, rather than singling out a few (one of which is a
duplicate of another anyway)?

The point of mentioning the duplicate issue is that multiple people have run
into the same problem over a long period of time.

Moreover, is 282 really a forward reference issue?

I can't find any other good explanation. As far as I know those kinds of
"type blah blah blah does not exist" when dealing with nested types comes up
most often when one thing is semantically analyzed before the type it
depends upon has been, so even though the error doesn't say "forward
reference" it's a side effect of the same issue.

At the conference, I was asked in various ways how bug fixes and
improvements are prioritized, given that so much needs to be done.
The short answer is, it's ad hoc. The longer answer is I have some vague
notion of whatever bubbles to the top of a cost/benefit analysis.