On Tuesday, 18 October 2016 at 23:02:28 UTC, Ali Çehreli wrote:
> I have a friend who has started writing a library in D.
>
> Although I recommended that he should use a recent dmd or ldc, he thinks gdc is a better candidate because it's "available to the masses" through Linux distros similar to how gcc is. Although he has a good point, the gdc that came with his distro does not even support @nogc.
>
> Thoughts? Can you please tell him to change his mind! :p
>
> Ali

For an example, Fedora's default repository ONLY has LDC, because GDC is not yet merged into GCC. The reason why Ubuntu does is because they have relaxed policy regarding GCC.

I think LDC is in most major distros, GDC is not, so LDC is the clear winner here. I build GDC myself and use it on Fedora, it is pretty straightforward, but I would recommend LDC to beginners. Once GDC is merged into GCC, it is a no-brainer - GCC/GDC all the way!

Dne 19.10.2016 v 12:15 Daniel Kozak napsal(a):
> Dne 19.10.2016 v 12:05 bachmeier via Digitalmars-d napsal(a):
>
>> On Wednesday, 19 October 2016 at 07:37:33 UTC, qznc wrote:
>>> On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:
>>>> According to this page
>>>> https://gdcproject.org/downloads/
>>>> there are only distro packages for Ubuntu, Debian, and Arch. If that's accurate, there really is no sense in which GDC is more available than DMD.
>>>
>>> Yes it is. Installing gdc is just "apt install gdc" on Ubuntu without looking for any download sites.
>>
>> That doesn't work if you're on Fedora, opensuse, or whatever new distro happens to be popular this week.
> Not true, as my previos comment mentioned almost every popular distro nowdays have ldc and gdc in repositories. But only few of them have dmd
Btw. I belive that future is in http://flatpak.org or similar concepts

On Wednesday, 19 October 2016 at 10:15:49 UTC, Daniel Kozak wrote:
> Not true, as my previos comment mentioned almost every popular distro nowdays have ldc and gdc in repositories. But only few of them have dmd

most of the distros just can't. they with to repackage/rebuild it, and boom! it is forbidden. proprietary backend license seriously backstabbing dmd.

On Wednesday, 19 October 2016 at 10:21:43 UTC, Dejan Lekic wrote:
> because GDC is not yet merged into GCC.

there is absolutely no reason to do this. while today the question of syncing gdc frontend with dmd is only a question of manpower, with such a merge gdc will *always* be behind, stucked with old versions. and for D this is critical, as each new D version brings something better, fix some bugs and so on. it's not like C, for example, for which you don't have new language/stdlib release each several monthes.

tl;dr: if gdc will be merged to gcc, it will be bad for D, and unrecoverable death for gdc.

On 10/18/2016 07:02 PM, Ali Çehreli wrote:
> I have a friend who has started writing a library in D.
>
> Although I recommended that he should use a recent dmd or ldc, he thinks
> gdc is a better candidate because it's "available to the masses" through
> Linux distros similar to how gcc is. Although he has a good point, the
> gdc that came with his distro does not even support @nogc.
>
> Thoughts? Can you please tell him to change his mind! :p
>
> Ali

The last GDC release is stuck all the way back at DMDFE v2.066, which is over two years old. Very few libs/projects are going to still be supporting that, there's just too much limitation going back that far. LDC had been keeping up much better.

Due to incompatibilities and necessary features/bugfixes, pretty much all of my projects have already been forced to drop support for DMDFE v2.066, and GDC in the process. And I *prefer* to maintain compatibility as far back as I can.

If his lib isn't tested to support up-to-date D compilers (especially the import changes in 2.070, but there's other stuff as well), that's going to prevent a lot of people from being able to use his lib. So much for availability to the masses.

And LDC (and DMD, frankly) is every bit as "available to the masses" as GDC. The "available to the masses" just seems based more on general perception of "GCC" being a big, major name rather than anything concrete.

On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
> On the other hand LDC subjectively offers a couple more D specific enhancements, like turning GC allocations into stack allocations in trivial cases

Whoa, seriously? I know it's a bit off-topic, but do you have a code example of where this would happen? That's amazing!

On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 10/18/2016 07:02 PM, Ali Çehreli wrote:
>>
>> I have a friend who has started writing a library in D.
>>
>> Although I recommended that he should use a recent dmd or ldc, he thinks gdc is a better candidate because it's "available to the masses" through Linux distros similar to how gcc is. Although he has a good point, the gdc that came with his distro does not even support @nogc.
>>
>> Thoughts? Can you please tell him to change his mind! :p
>>
>> Ali
>
>
> The last GDC release is stuck all the way back at DMDFE v2.066, which is over two years old. Very few libs/projects are going to still be supporting that, there's just too much limitation going back that far. LDC had been keeping up much better.
>

The core devs are becoming much more receptive to the idea of a release that has fixes maintained for longer periods of time.  While I welcome this, it may have come too little, too late.

And GDC is using the 2.068 feature set, plus a lot of bug fixes from later versions.  I guess you could call it 2.068.5.  :-)

> Due to incompatibilities and necessary features/bugfixes, pretty much all of my projects have already been forced to drop support for DMDFE v2.066, and GDC in the process. And I *prefer* to maintain compatibility as far back as I can.
>
> If his lib isn't tested to support up-to-date D compilers (especially the import changes in 2.070, but there's other stuff as well), that's going to prevent a lot of people from being able to use his lib. So much for availability to the masses.
>

The fixes to import behaviour only breaks forwards compatibility, not backwards compatibility.

The problem with compatibility is a library problem, not a compiler IMO.

On 19 October 2016 at 21:25, TheGag96 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
>>
>> On the other hand LDC subjectively offers a couple more D specific enhancements, like turning GC allocations into stack allocations in trivial cases
>
>
> Whoa, seriously? I know it's a bit off-topic, but do you have a code example of where this would happen? That's amazing!
>

Not to be the one to downplay something.  But it's actually pretty boring. ;-)

An example in GDC would be where a closure was created, but the nesting function was inlined or optimized away.

In the latter case, you may see something like the following in the DCE pass.

int foo()
{
  closure = _d_allocmemory (8);
  closure.bar = 0;

  return 0;
}

Using a mixture of having a closure that is set but never read, and giving the optimizer the right hints about what "allocmemory" does means that it removes the call as dead code.

The exact same is done in the former case, you just convert the closure to a stack frame, removing the dead call the allocmemory.

On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
> I'd say start with DMD, as it comes practically free of dependencies […]

The same applies to LDC. If you want, you can use the self-contained binary releases, which just require the system linker to be present, like DMD does.

 — David

On 10/19/2016 05:13 PM, Iain Buclaw via Digitalmars-d wrote:
> On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d
>>
>> The last GDC release is stuck all the way back at DMDFE v2.066, which is
>> over two years old. Very few libs/projects are going to still be supporting
>> that, there's just too much limitation going back that far. LDC had been
>> keeping up much better.
>
...
> And GDC is using the 2.068 feature set, plus a lot of bug fixes from
> later versions.  I guess you could call it 2.068.5.  :-)
>

Maybe there's a certain amount of truth to that, but not completely: In all my projects anyway, the latest available GDC on travis always broke at exactly the same time DMD 2.066 and below broke. I don't think I have any remaining projects that still work on GDC, but several still work on DMD 2.067.1 (not sure about 2.067.0, don't use that one in my .travis.yml files since 2.067.1 came out).

Maybe there's a newer GDC build that isn't on travis yet? Current lastest (using "gdc" in .travis.yml), checked as of 13 hours ago, is reporting this:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 20150825-2.066.1-58ec4c13ec) 4.9.3

There's also a "gdc-5.2.0" that (checked as of this past April, anyway - not sure if there would be a newer "gdc-5.2.0" though), reports:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 20150825-2.066.1-dadb5a3784) 5.2.0


>> If his lib isn't tested to support up-to-date D compilers (especially the
>> import changes in 2.070, but there's other stuff as well), that's going to
>> prevent a lot of people from being able to use his lib. So much for
>> availability to the masses.
>>
>
> The fixes to import behaviour only breaks forwards compatibility, not
> backwards compatibility.
>

Not sure what your point is here. If you're writing a library and want to avoid giving your users deprecation messages due to the import changes, then you need to test on 2.070 or newer. Clean compilation on pre-2.070 does not guarantee clean compilation on 2.070+.

> The problem with compatibility is a library problem, not a compiler IMO.
>

Since compiler versions and druntime/phobos versions are still pretty much a packaged deal, the distinction is irrelevent.