It makes me sick!

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Jul 27 16:37:41 PDT 2017


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




More information about the Digitalmars-d-learn mailing list