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>.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fash0i$11ie$1@digitalmars.com...
>
> 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.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fash0i$11ie$1@digitalmars.com...
>> 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.

Walter Bright escribió:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fash0i$11ie$1@digitalmars.com...
>>> 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>

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fasudc$1mvc$1@digitalmars.com...
>
> The problem is, forward references also have a high cost to fixing.

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.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fasudc$1mvc$1@digitalmars.com...
>> The problem is, forward references also have a high cost to fixing.
> 
> 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

Bill Baxter wrote:
> Jarrett Billingsley wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fasudc$1mvc$1@digitalmars.com...
>>> The problem is, forward references also have a high cost to fixing.
>> 
>> 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.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fasudc$1mvc$1@digitalmars.com...
>> The problem is, forward references also have a high cost to fixing.
> 
> 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.
> 
> 

Strongly agreed. Granted, part of it is because I'm on GDC, but even so,
I'm regularly surprised how unstable stuff is, especially when you start
prodding corner cases. I'd choose a reliably-working 1.0 over a nice,
but borked 2.0 anyday.
Just my ¢2. --downs

torhu wrote:
> Bill Baxter wrote:
>> Jarrett Billingsley wrote:
>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fasudc$1mvc$1@digitalmars.com...
>>>> The problem is, forward references also have a high cost to fixing.
>>>
>>> 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

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:fasrq6$1iml$1@digitalmars.com...
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:fash0i$11ie$1@digitalmars.com...
>>
>> 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.