Which D compiler is the most maintained and future-proof? [DMD GDC and LDC]

[Steven Schveighoffer]

On 7/24/23 9:30 AM, cc wrote:
> On Monday, 24 July 2023 at 09:29:09 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> There isn't a huge concern with which one you use.
>>
>> Its quite common to use dmd for development, and ldc for release for 
>> example.
>>
>> They all share the same frontend, so they really only differ between 
>> them by their glue code to the relevant backend and some modules in 
>> druntime that are optional. Oh and inline assembly, although there is 
>> some compat code in ldc/gdc for dmd style.
>>
>> If dmd dies, so does ldc/gdc basically. Each one sees active 
>> development although gdc only has one developer. Ldc keeps up with the 
>> dmd releases pretty well.

If DMD dies, the other two will live on. This is open source after all.

> 
> Is there any list of known significant "gotchas" with moving to LDC from 
> DMD?  Any unexpected surprises to watch out for or be careful for?  I'm 
> thinking of all the "features" of DMD that are now considered verboten 
> by many users (e.g. compiling with -release, disabling of asserts or 
> array bounds checking, etc). Known edge cases of compiler optimization 
> causing different behavior between vendors?
> 

DMD is the point of all D feature introductions, and so anything that 
works with LDC should work with DMD.

It's the other way around that might cause trouble, since there may be 
DMD features which haven't yet made it into LDC.

There are also subtle ways to consider things "broken" which might 
affect you if you care about that. Like for instance floating point 
handling is different, so you might not get exactly the same binary results.

-Steve