D as first class language in the gcc milestones ?

[Iain Buclaw via D.gnu]

On 28 Sep 2014 09:50, "Ledd via D.gnu" <d.gnu at puremagic.com> wrote:
>
> On Saturday, 27 September 2014 at 12:20:01 UTC, Iain Buclaw via D.gnu
wrote:
>>
>> On 27 September 2014 13:11, ketmar via D.gnu <d.gnu at puremagic.com> wrote:
>>>
>>> On Sat, 27 Sep 2014 11:47:33 +0000
>>> "Ledd via D.gnu" <d.gnu at puremagic.com> wrote:
>>>
>>>> I don't think that the gcc team is slow on releasing new releases
>>>> and patches
>>>
>>> they are much slower than D team.
>>>
>>>> I think that on one hand it's true that D is
>>>> currently a rapidly-changing language, but this also prevents a
>>>> gain in popularity, no one wants to adopt a non-standard language
>>>> that is constantly mutating for production code.
>>>
>>> at least three companies already adopted D: Facebook, Sociomantic
>>> and... sorry, i forgot the third. so your "no one" is a slight
>>> exaggeration. ;-)
>>>
>>>> My assumption is that D needs to freeze at some point .
>>>
>>> ahem... we already have C++. ;-) it's not frozen, but it's legacy turned
>>> it to abomination.
>>>
>>> i believe that shipping old D in distributives will harm D more than
>>> not shipping at all. people will write new code using obsolete
>>> features, fight with already-fixed bugs, and so on. being independent of
>>> GCC allow to avoid such problems, 'cause maintainer can build new
>>> package when new GDC is out. but if GDC will be the part of GCC, no
>>> updates will ship until new GCC is out, 'cause GDC release cycle will be
>>> dependent of GCC release cycle.
>>>
>>
>> And for sure, the team pushing for DDMD will have to be a little more
>> backwards compatible than previous release can build next release.
>
>
> I can't see the problem, do you think that a rolling-release language is
good for its own popularity and diffusion ?
>
> 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 .

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.

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.

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.

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20140928/a35b0671/attachment.html>