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