Robert Clipsham wrote:
> Walter Bright wrote:
>> 314 does not affect correct code, hence is an implicitly less important issue.
> 
> It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.

Stewart Gordon wrote:
> With the amount of time that has passed since DMD 1.00 was released, people would have expected the language spec to be at a stable state by now.

Would you like to submit some revisions to it?

Robert Clipsham wrote:
> Stewart Gordon wrote:
>> (a) having a spec that the public agrees to be complete and consistent
> 
> I think this is probably the most important of your points. Without a complete and consistent spec, there's no possible way to make a correct compiler. All features need to be in there, explaining how they should work in detail. This is a blocker for anyone who wants to write a D compiler currently, they have to go by dmd in some cases rather than the spec.

Exactly what I had been trying to say.

<snip>
> I guess this is up to Walter. Would D 1.1 just be a milestone for D, or would it need a new spec? Maybe D 1.1 could be a fork of D1 which introduces the breaking changes and finalizes the spec? That way we don't have the issue of breaking D1.0. When it is complete D1.0 could be marked deprecated and D1.1 could take its place. Or of course the changes could take place in D1.0 and gradually introduce the breaking changes, making D1.1 the final result (or maybe just D1.098, however many revisions of the compiler it takes :P).

What would these breaking changes be?

AISI the right time to declare D1.1 is once bug 677 is done and dusted and the remaining spec issues (currently there are 43 non-enhancement issues with the spec keyword filed against D1 and pre-D1 versions) have at least had a go-over.

Stewart.

Walter Bright wrote:
> Robert Clipsham wrote:
>> Walter Bright wrote:
>>> 314 does not affect correct code, hence is an implicitly less important issue.
>> 
>> It does however include a patch, submitted almost a year ago I might add.
> 
> Yes, but the patch is incomplete.

I didn't know that was the reason for it not being applied! I'll dig out the changeset that folded it into LDC.

On Tue, May 12, 2009 at 2:00 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Robert Clipsham wrote:
>>
>> Walter Bright wrote:
>>>
>>> 314 does not affect correct code, hence is an implicitly less important issue.
>>
>> It does however include a patch, submitted almost a year ago I might add.
>
> Yes, but the patch is incomplete.

Then where is your comment on the issue to that effect?

You can't honestly expect people to submit patches if you're not going to give feedback as to why you won't include them!

Jarrett Billingsley wrote:
> You can't honestly expect people to submit patches if you're not going
> to give feedback as to why you won't include them!

Quite a lot of the submitted patches have been incorporated.

The patch report itself says it's incomplete.

Walter Bright wrote:
> Stewart Gordon wrote:
>> With the amount of time that has passed since DMD 1.00 was released, people would have expected the language spec to be at a stable state by now.
> 
> Would you like to submit some revisions to it?

Maybe it would be a good idea for someone to go through the spec and look for any areas that aren't clear or need expanding? We could create posts on the newsgroup to figure out what needs to be added/changed etc then submit revisions to you.

Walter Bright wrote:
> Christopher Wright wrote:
>> However, if a patch exists, there is only one excuse for not including it: lack of testing.
> 
> 
>> And there is one huge reason that nobody submits additional test cases to your DMD test suite -- you've never released it, or even specified the required format.
> 
> That's because of its uncertain copyright status. It's a collection of everything that went wrong in the past, from a wide variety of sources.

Understood.

> As to its format, it is designed to be run by a shell script. Each source file is expected to compile and run without error, error means terminating with an exception or a non-zero return from main().

Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla?

What do you do about examples that should explicitly not compile? For example, a test for the fix to an accepts-invalid bug? Do you have to use tricks with __traits(compiles) and static assert (!is (typeof))?

Christopher Wright wrote:
> Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla?

I think the wiki is the best place.

> What do you do about examples that should explicitly not compile? For example, a test for the fix to an accepts-invalid bug? Do you have to use tricks with __traits(compiles) and static assert (!is (typeof))?

I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.

On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:

> The order of importance of bugs is roughly:
> 
> 1. silently generating bad code
> 2. compiler crashes
> 3. regressions that break previously working code
> 4. not accepting valid code
> 5. accepting invalid code
> 6. poor error messages
> 
> Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.

This is useful and important information. IMO it should be on your website ASAP.

I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you.

A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell