It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Thursday, 27 July 2017 at 23:37:41 UTC, Jonathan M Davis wrote:
> 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


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!

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.

I should be able to put any extra files anywhere in the dmd2 dir 
structure and it should NOT break dmd.

It's like if I put a text file in some OS directory and the OS 
decides to use that file and crash the OS and not boot... it 
could happen, but it shouldn't.

In fact, all of phobos should be versioned. Each module should 
have a version id embedded in it. Each release all the versions 
are updated before shipping.