On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote:
You are not being very logical.
The zip file as N files in it. No matter what those files are,
it should be a closed system. That is, if I insert or add(not
replace) M file to the directory structure it should not break
D, period!
That's *not* what happened here. Jonathan explained it quite
well. std.datetime was refactored into a package, its contents
split into new modules. When you import a module foo, dmd looks
for:
1. foo.di
2. foo.d
3. foo/package.d
When it finds one, it stops looking. It's not an error for all
three to exist. Your error came because it found std/datetime.d,
but you linked to a library that included symbols for
std/datatetime/package.d. It's not the compiler's responsibility
to error in that case. It's your responsibility to properly
install.
Why? Because NO file in the zip should be referencing any file
not in the zip unless it is designed to behave that way(e.g.,
an external lib or whatever).
If an old external program is referencing a file in dmd2 that
isn't in the new zip it should err.
Why? Because suppose you have an old program that references
some old file in dmd2 dir and you upgrade dmd2 by extracting
the zip. The program MAY still work and use broke functionality
that will go undetected but be harmful.
Why? Because dmd.exe is reference a file it shouldn't and it
should know it shouldn't yet it does so anyways. It really has
nothing to do with the file being in the dir but that dmd is
being stupid because no one bothered to sanity checks because
they are too lazy/think it's irrelevant because it doesn't
effect them.
That's unreasonable.
I should be able to put any extra files anywhere in the dmd2
dir structure and it should NOT break dmd.
There are numerous applications out there that can break if you
simply overwrite a directory with a newer version of the app. DMD
is not alone with this. You should always delete the directory
first. It's precisely why the compiler does so.
