2015-06-01 20:03 GMT+02:00 Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com>:

The main problem is we don't have ABI compatibility. This means we can't
share the libraries between compilers. So we could make 'import foo'
work but linking with -lfoo without manually adjusting linker paths is
not possible.

There are some solutions, all have drawbacks:
* Have compiler specific directories for libraries
  (/usr/lib/gdc/libvibed.a, /usr/lib/dmd/libvibed.a). Only works for
  static libraries. Can only have one version of a library installed
* have per-library directories. I guess dub uses this. Can have
  multiple versions of the same library. Drawback: compiler can't know
  the correct library path.[1]
* Shared libraries should be installed in a common location (/usr/lib)
  anyway. This is only possible if we have ABI compatibility[2].
  Library versioning is limited to the standard C/C++ like versioning.

I guess the main reason why we can't have a C/C++ like out of the box
experience is ABI compatibility. There'll always be some quirks as long
as we don't fix this.


Glad to see that post !

But in addition of the ABI compatibility between compilers, we would need to have ABI compatibility between releases of the same major version if we were to walk the C[++] route, and we do not want that, for various reason, the most obvious one being that you won't be able to add an attribute like @nogc / nothrow to a free function without doing a major release.

There is good thing about C way of doing thing, but there is also some bad. For example, you can't have multiple versions of the same library installed - you don't need it -, but D definitely needs that. That also leads to major releases ending up in a different package - think qt4 / qt5 -. So, while C use SemVer for ABI compatibility, we should use SemVer for source compatibility, or we'll end up with an unmanageable mess.