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