Am Thu, 11 Sep 2014 07:12:49 +0100
schrieb Iain Buclaw via Digitalmars-d
<digitalmars-d@puremagic.com>:

> By way of example, the version of D shipped with gcc-4.9 in Debian/Ubuntu is 2.065, if we were to switch now, then that compiler version will need to be able to build whatever will be the current when gcc-5.0 comes out.
> 
> Iain.

For Gentoo I used the third version component as well. I found it better matches the D release cycle:

4.8.1 => 2.063
4.8.2 => 2.064
4.8.3 => 2.065

-- 
Marco

On 11 September 2014 11:13, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thu, 11 Sep 2014 11:54:08 +0200
> Daniel Kozak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> What? I don't see any problem with binary blob. With gcc it is same I need binary blob to be able to compile gcc from source. And if I am really scary of binary dmd compiler I can still use last C++ version and compile it with gcc, then use this product to compile next ddmd and so on.
> as i said -- good luck with it. D is not GCC (yet?), and GDC is not a part of GCC. it's very naive to assume that FOSS programmer that wants to try D will take last C++ version, then compiles it, than compiles next D version and so on. he will take either gdc from distro repo (and this will be old, if not ancient) just to find that it has no shiny new features the programmer just read about in NG, or will try to build HEAD and... and drop D, 'cause "if they make it so hard to build their compiler, they can play with it without me".
>

Two ways of looking at it, this is a problem if:

1) A distribution doesn't ship gdc already (ie: opensuse, fedora)
2) A developer building gdc doesn't have a D compiler available.

As for binary blob, well, gcc had to start from somewhere, and was originally too built by a closed source binary blob.

If you are concerned, enable bootstrapping, that will give you an ethically clean compiler.

> inability to be built with GCC out-of-the-box pushing D into marginality. and inability to use new shiny compiler features 'cause compiler should be buildable with previous versions too. and this will effectively kill language progress:
>

Just because the compiler is not implemented with shiny new features, does not stop progress of implementing shiny new features.

Iain.

On Thu, 11 Sep 2014 15:07:48 +0100
Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Just because the compiler is not implemented with shiny new features, does not stop progress of implementing shiny new features.
but using new features by compiler authors themselves will allow faster adoption and better testing. and why don't use D in all it's glory for compiler code? some people will look at compiler code to find "idiomatic" way of doing things. and if compiler writers themselves avoid new features... well, that means that those new features are dangerous and untested and better be avoided.

On 11 September 2014 15:31, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thu, 11 Sep 2014 15:07:48 +0100
> Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Just because the compiler is not implemented with shiny new features, does not stop progress of implementing shiny new features.
> but using new features by compiler authors themselves will allow faster adoption and better testing. and why don't use D in all it's glory for compiler code? some people will look at compiler code to find "idiomatic" way of doing things. and if compiler writers themselves avoid new features... well, that means that those new features are dangerous and untested and better be avoided.

That's not a very accurate view at all.  GCC and Clang are written in a very idiomatic C++, but does that make people think C++x14 features are dangerous and untested?

Iain.

On Thu, 11 Sep 2014 15:38:21 +0100
Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That's not a very accurate view at all.  GCC and Clang are written in a very idiomatic C++, but does that make people think C++x14 features are dangerous and untested?
being "blessed by committee" has it's advantages. ;-)

there is no "D committee" (thanks to all existing and inexisting gods for that!), so the only source of trust is compiler developer(s). if compiler developers avoid using new features, those features aren't "blessed", they are dangerous and all that.

On Thursday, 11 September 2014 at 15:24:41 UTC, ketmar via Digitalmars-d wrote:
> if compiler developers avoid using new features, those features aren't "blessed", they are dangerous and all that.

Wat.

Right now, the D compiler (obviously) doesn't use any D features at all. I'm not sure how you come to the conclusion that being able to use the features from, say, a couple of releases ago is worse than that.

David

On Thursday, 11 September 2014 at 15:24:41 UTC, ketmar via Digitalmars-d wrote:
> there is no "D committee" (thanks to all existing and inexisting gods
> for that!), so the only source of trust is compiler developer(s). if
> compiler developers avoid using new features, those features aren't
> "blessed", they are dangerous and all that.

This is already the case with the pure C++ version of dmd, as David said, since D is currently not used to write any of the D compilers.

As for your point about requiring a working D compiler installed to experiment with building a D compiler from git, it is a valid concern, but I don't think it's a big deal to trade raising that small barrier to have a partially self-hosting compiler.  Maybe it'd be better to have your D->C++ translator and keep the C++ fallback, but barring anyone willing to actually work on that, it's obviously not going to happen.

On Thu, 11 Sep 2014 17:20:51 +0000
David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Right now, the D compiler (obviously) doesn't use any D features at all. I'm not sure how you come to the conclusion that being able to use the features from, say, a couple of releases ago is worse than that.
i expected this argument. and i don't event want to start arguing about C++ code that isn't using D features.

On Thu, 11 Sep 2014 17:32:49 +0000
Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> it'd be better to have your D->C++ translator and keep the C++ fallback, but barring anyone willing to actually work on that, it's obviously not going to happen.
i *was* willing to work on it. not anymore.

On Thursday, 11 September 2014 at 17:33:14 UTC, ketmar via Digitalmars-d wrote:
> On Thu, 11 Sep 2014 17:20:51 +0000
> David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Right now, the D compiler (obviously) doesn't use any D features at all. I'm not sure how you come to the conclusion that being able to use the features from, say, a couple of releases ago is worse than that.
> i expected this argument. and i don't event want to start arguing about
> C++ code that isn't using D features.

So what exactly is your argument then?

David