On 7/24/11 4:31 AM, Mike Wey wrote:
On 07/23/2011 11:54 PM, Andrei Alexandrescu wrote:
The problem with this setup is that it's extremely fragile, in ways that
are undetectable during compilation or runtime. For example, just
swapping a and b in the implementation file makes the program print
"08.96566e-31344". Similar issues occur if fields or methods are added
or removed from one file but not the other.
In an attempt to fix this, the developers may add an "import a" to a.d,
thinking that the compiler would import a.di and would verify the bodies
of the two classes for correspondence. That doesn't work - the compiler
simply ignores the import. Things can be tenuously arranged such that
the .d file and the .di file have different names, but in that case the
compiler complains about duplicate definitions.
If the .di files are this fragile, the compiler should just always check
if the .d file matches (if present) .di file, then there is no need for
the extra import.
Trouble is, they sometimes may be in different dirs.
Andrei
