typedef alive and well?

[Martin Nowak]

On Thu, 03 Nov 2011 23:42:01 +0100, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Martin Nowak:
>
>> I think there's a lot to learn from  
>> http://python.org/download/releases/.
>> For example somebody changing from Python2.5 to 2.7 is anticipating
>> some breaking changes, not so much for a change from dmd2.053 to  
>> dmd2.056.
>
> There is a difference between Python 2.5 and the current D2. D/DMD  
> contains several unfinished features (see recent large changes in inout  
> or CTFE), and several design holes that are quite open still (array  
> covariance, purity details to be fixed still, some parts of the const  
> system, etc). So while Python2.5 is a mature language that is  
> essentially only gaining new features (slowly, there was even a  
> moratorium for the enhancements, to allow pypy and jython to catch up,  
> that was recently lifted), D2 despite its age is not mature yet, and it  
> probably needs some changes still, maybe some small breaking too. (I am  
> keeping a list less than a dozen of tiny breaking changes for D, most of  
> them were not discussed much yet).
>
> Bye,
> bearophile

That's exactly the point, there are quite a lot of unfinished features that
affect code. This does not only cause regressions but lets one run into
frustrating deadends (a domain C++ sets the gold standard for).

Just to name a few walls I hit regularly.
  - const, inout functions
  - lots of math in CTFE but no exp/log family functions
  - quite some tuple improvements but also many unexpected black holes

The systematic misconception is to handle these features as bugfixes.
They are even (partly) tracked in bug reporting tool.
Developing feature specs deserves to be a separate process.

Experimental or unfinished features should not get into the
mainline branch.
Depending on the size of a feature there should at least be a rough  
concept.
Implementing features out of opportunity will ultimately
turn everything into spaghetti.

I would also like to see that the regular enhancement request bombardment
were turned into something productive. The 1.5 day attention span on the
mailing list are definitely not fruitful for language developing.


And because this is all too negative, I propose the following process
using the language specifications at github:d-programming-language.org.

- The language specifications are made version specific (e.g. 2.6, partly  
handled by tags already).

- Branches are created for the next 2(?) minor versions ahead of the  
current release cycle.
   Another one is created for the next major version.

- We adopt a pull based development for the language specification similar
   to that for phobos (review queue, review manager, voting).

- Specs are lined with acceptance tests. Ideally this would be the code  
examples.

- The compiler strives to fulfill the specs.

- Specs are added to the autotester.

Not sure if github:d-programming-language.org can handle all this  
appropriately,
but it seems worth a try.