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

On Thu, 03 Nov 2011 23:42:01 +0100, bearophile <bearophileHUGS@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.

On Thu, 03 Nov 2011 20:47:48 +0100, Marco Leise wrote:

> Am 03.11.2011, 18:43 Uhr, schrieb Steve Teale <steve.teale@britseyeview.com>:
> 
>> On Thu, 03 Nov 2011 13:22:49 -0400, Jonathan M Davis wrote:
>>
>>> On Thursday, November 03, 2011 09:22 Steve Teale wrote:
>>>> I see that Walter just fixed a typedef bug in 2.056, even though I was just ticked of for even thinking of using one ;=)
>>>
>>> He probably fixed it because it hasn't actually been given the axe yet, but it's definitely going to get the axe - and probably soon, since there was some discussion of wanting to remove (or at least deprecate) features that are definitely going to be removed before gdc actually makes it into gcc so that the changes are less disruptive when they happen.
>>>
>> Jonathan,
>>
>> I thank you for your reply. I was just watching Sarkozy at the G20 talking about the potential Greek referendum. He took a similarly firm
> It caused some discussion. Someone didn't like the naked-function feature or other traits of D that (official) support has to be written for in the GCC backend first. But I don't see how D would become unbearable for the GCC people as long as the frontend is maintained. There have been other language frontends bitrotting before, so the 'Eurozone' is suspicious and looks closely on who is joining them. Since D in GCC is often requested I believe it will have a positive future there and give the language more momentum, since people don't have to leave their known and pre-installed tool chain.

I was thinking of us as Greece and them as Eurozone - what effects on DMD?