On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote: > On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: > > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: > >> But the issue was about missing symbols, not anything "extra". If > >> datatime.d is there but nothing is using it, why should it matter? > > > > YOU were using it with an `import std.datetime;` line. With the file > > still there, it sees it referenced from your code and loads the file... > > but since it is no longer used upstream, the .lib doesn't contain it and > > thus missing symbol. > > So, the actual problem is that given both > > datetime/package.d and > datetime.d, > > the import statement prefers the file. It could produce a compilation > error. > > If we don't want that extra check by the compiler, it would be better to > keep datetime.d with a warning in it about the change. The warning could > say "please remove this file". :)
I think that this should obviously be a compilation error as should any case where you've basically declared the same module twice. And really, I don't see any reason to support extracting the new zip on the old folder. We've never said that that would work, and if you think it through, it really isn't all that reasonable to expect that it would work. The list of files changes from release to release (even if removals are rare), and the layout of the directories could change. So long as the sc.ini or dmd.conf does ther right thing, then that really isn't a problem. Obviously, it's more of a pain if folks are making manual changes, but we've never promised that the directory structure of each release would be identical or that copying one compiler release on top of another would work. - Jonathan M Davis
