D is coming to a town near you
Rob T
alanb at ucora.com
Wed Feb 20 11:21:29 PST 2013
On Wednesday, 20 February 2013 at 18:42:42 UTC, bearophile wrote:
> Rob T:
>
>> and do a ton of boring stuff like stabilize D2/Phobos before
>> moving on to D3, install better processes for documentation
>> and developing the language specifications, and of course
>> continue to improve the release process (it still needs a real
>> beta and stable release), etc.
>
> "Stabilize" is the wrong word to use. Implementing the 64
> compiler is good, implementing shared libraries is good,
> porting D runtime/Phobos to RISC CPUs is good, replacing the GC
> is good, improving the floating point management by DMD is
> good, and so on and on.
>
> But in my opinion what's more needed now is instead to try to
> complete as much as possible the design and implementation of
> the missing/broken/incomplete parts of the core language (like
> finishing const/immutable design, finishing the implementation
> of pure, redesigning properties, fixing @trusted, doing what's
> possible with shared, doing what's possible to finish the
> inference of tags like pure in templated functions, finishing
> the design of packages, finishing the implementation of the
> module system, finishing the design of operator overloading,
> and so on. The complete list of broken/unfinished parts scares
> me).
>
> Bye,
> bearophile
Yes your additions is included in what I meant by "stabilize". We
need to freeze the addition of new features for the "stable
release of the language" (we currently do not have a stable
release that is documented) and put it through the acid test of
real world use so it can be polished up based on the feedback.
It may be a good idea to create a team that concentrates only on
releasing a stable version of the language and polishing it up,
otherwise it will never get done. We cannot polish up an
undefined moving target, it's as simple as that.
--rt
More information about the Digitalmars-d
mailing list