<p dir="ltr">On 28 Sep 2014 09:50, "Ledd via D.gnu" <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
><br>
> On Saturday, 27 September 2014 at 12:20:01 UTC, Iain Buclaw via D.gnu wrote:<br>
>><br>
>> On 27 September 2014 13:11, ketmar via D.gnu <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
>>><br>
>>> On Sat, 27 Sep 2014 11:47:33 +0000<br>
>>> "Ledd via D.gnu" <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
>>><br>
>>>> I don't think that the gcc team is slow on releasing new releases<br>
>>>> and patches<br>
>>><br>
>>> they are much slower than D team.<br>
>>><br>
>>>> I think that on one hand it's true that D is<br>
>>>> currently a rapidly-changing language, but this also prevents a<br>
>>>> gain in popularity, no one wants to adopt a non-standard language<br>
>>>> that is constantly mutating for production code.<br>
>>><br>
>>> at least three companies already adopted D: Facebook, Sociomantic<br>
>>> and... sorry, i forgot the third. so your "no one" is a slight<br>
>>> exaggeration. ;-)<br>
>>><br>
>>>> My assumption is that D needs to freeze at some point .<br>
>>><br>
>>> ahem... we already have C++. ;-) it's not frozen, but it's legacy turned<br>
>>> it to abomination.<br>
>>><br>
>>> i believe that shipping old D in distributives will harm D more than<br>
>>> not shipping at all. people will write new code using obsolete<br>
>>> features, fight with already-fixed bugs, and so on. being independent of<br>
>>> GCC allow to avoid such problems, 'cause maintainer can build new<br>
>>> package when new GDC is out. but if GDC will be the part of GCC, no<br>
>>> updates will ship until new GCC is out, 'cause GDC release cycle will be<br>
>>> dependent of GCC release cycle.<br>
>>><br>
>><br>
>> And for sure, the team pushing for DDMD will have to be a little more<br>
>> backwards compatible than previous release can build next release.<br>
><br>
><br>
> I can't see the problem, do you think that a rolling-release language is good for its own popularity and diffusion ?<br>
><br>
> The only credible alternative is that you make D extremely easy to refactor via automated tools so you can change it as much as you want while keeping the codebase working .</p>
<p dir="ltr">To give one example, you can build gcc-4.8 using gcc-4.6, in which time, there have been up to a dozen or so D language releases, and let's say every other release has introduced a backwards incompatibility feature that required applying to Phobos immediately.</p>
<p dir="ltr">Why is this bad?  One thing that will change when gdc is part of gcc is that suddenly, more or less every Linux distribution (or at least the big distros) will start shipping gdc through their software repositories, and will only update them according to their own release schedule.</p>
<p dir="ltr">So ensuring that ie: gdc-5.1 can build gdc-5.2 when we switch to a self-hosted compiler is a pretty big deal.  And what I can see happening is either we'll fall behind the latest spec more rapidly, or minor releases will get very selective backports.  Neither of which I like the idea of doing.</p>
<p dir="ltr">Iain.<br></p>