Finalizing D2

Jason House jason.james.house at gmail.com
Fri May 22 18:04:21 PDT 2009


dsimcha wrote:

> == Quote from Jason House (jason.james.house at gmail.com)'s article
>> Andrei has indicated that the current plan is to finalize D2 when his
>> book comes
> out.
>> Given this, I'm interested in what _community_ activity should be done as
>> part
> of this.
>> Should there be a formal review and polishing of the D spec? More than
>> just
> criticizing faults, people should submit patches or open a discussion of
> what something means. Unimplemented features should be clearly marked or
> removed.
> 
> Given that it's a fairly daunting task to review every dark corner of the
> spec, I think D2 will initially need to be declared somewhere between
> alpha and stable,
> i.e. beta, at least for a while.  This means no changes that break code in
> non-trivial ways, i.e. ways that require significant portions to be
> redesigned, but things like bug fixes that break a few corner cases that
> rely on the bug are ok.


Given how Andrei's book is at least half written, I'm going to guess that 
*all* major features for D2 have been decided.  Maybe the TLS change was the 
last breaking change.  Having a 100% stable dmd compiler isn't really 
required.  All that is needed is for everyone to understand what is planned.  
I think that's pretty easy to do.  Even if there are a few small surprises 
along the way, it should be possible to update one small part of the spec.

Obviously, it really doesn't make a lot of sense for the community to go 
forward with stuff like this without at least a confirmation that such 
efforts won't be in vain.  (A recurring element in all of these ideas is 
that at least a small amount of effort/communication is needed by D's core 
contributors, but that the bulk of the work is placed on the community as a 
whole instead of on them)

It'd be nice if we could start setting a date for when D2 will put a freeze 
on major features (maybe call it a beta release, a release candidate, 
whatever)


>> Should the final freezing of D2 be delayed until major D1 libraries port
>> to D2?
> I'm mostly thinking of Tango, but I bet there are others. It may even be
> good if major libraries could use a Phobos-compatible license and become
> part of the releases by digital mars.
> 
> Good question, it's kind of a chicken and egg problem.  My gut feeling is
> that D2
> must be frozen so that it's not a moving target and those ports can
> happen.  On the other hand, if the Tango people need one or two small
> changes to the core
> language to simplify their port, it could be worth implementing.  On the
> other hand, the Tango people have been pretty clear about what they need,
> which is mostly a stable spec and one or two small enhancements that have
> already been filed in Bugzilla.

It is definitely a chicken and egg problem, but I think it's relatively easy 
to work through.  All we need is a period of relative stability where 
changes are driven mostly by deviations from a D2 spec.

Actually that makes me realize that this should probably be a sequential 
process.  Maybe we finalize the spec first before pushing for any final 
fixes.  It's probably possible to even have other features going into the 
compiler while the spec is developed, but I think it can't be something 
drastic like a replacement const system ;)


> Also, I think it would be worth it to eventually nominate a few generally
> useful modules from various community-developed libs for inclusion in
> Phobos, but non-breaking additions to Phobos don't really need to be
> completed before D2 is finalized.

I agree.  When D2 spec, compiler, and libs are in shape for finalization, 
there should be a decision on if the libraries for D2 should freeze along 
with the compiler specification.  I'm guessing Walter will vote yes, but I 
bet some will want something more than the D2 equivalent of "D1 Phobos a 
dead library.  Let's all use Tango that's better maintained."


>> Can we generate a bugfix most wanted list? The formal list could inspire
>> patches
> by motivated community members. There should be a quality requirement and
> a review process for submissions.
> 
> This is pretty much already done via the voting feature in Bugzilla.

That may be, but there are a few other important nuances:
1. Only bugs relative to the D2 spec should matter.  Feature enhancements 
(and bugs who's fix would essentially require an enhancement) should not be 
considered.
2. Once a set of bugs are selected, someone should start soliciting patch 
submissions from the community.  
3. Not everyone votes on bugs, so if that's the way this is done, it should 
be made official.  Once it's official, I can guarantee there will be more 
votes in bugzilla!




More information about the Digitalmars-d mailing list