On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote:
q could be a completely different type in a.dll vs. c.dll.
Please correct me if I am wrong, but my understanding of how
import libs get used you can't detect this at build time and
disallow it. Linking d.exe we have no reason to look at a.lib
and notice the conflict, and even if we did there's no type
information to go off of anyway and you could assume that they
were the same.
No q can not be a different type in a.dll vs c.dll
Because of the mangling of the type it would be called a.q once
and c.q so no conflict would arise.
If you define the same type within the same module but it behaves
differently depending on where it is used (e.g. depending on
compiler flags -version -debug etc), this is already an issue and
will also explode with static libraries. So nothing new here. The
user of the language has to ensure that all uses of a type see
the same declaration of the type.
Is your intent to only apply this unification to extern (D)
symbols?
Why not? I can't think of anything special about extern (D)
declarations. Just as a reminder, linux already does this for
_all_ symbols. And it doesn't cause any issues there.
