On 8/1/17 10:29 AM, Adam D. Ruppe wrote:
On Tuesday, 1 August 2017 at 14:20:00 UTC, Steven Schveighoffer wrote:
But the fix here is to fix the bizarre package.d design. Don't break
the zip for cases like mine where adding files is a key feature of it.
How should it be fixed?
Well, my preference would be to treat it just like any other module: the
compiler has a search path, but if it opens a file, the module name is
definitive.
So we can keep the search path: `datetime.di`, then `datetime.d`, then
`datetime/package.d`, and any one of them, as long as it has `module
std.datetime;` at the top, can count equally as the package.d.
I don't remember the reason why we can't just have foo/... and foo.d and
needed to use foo/package.d to do this.
It does fail to compile though if I use foo.d instead of package.d:
foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module
name in file foo.d
BTW I kinda want to put `datetime/package.d` first on the search path,
but I fear that'd hurt the speed of the normal case (every import would
mean 2 file not found queries until it actually finds the common
`file.d`)... but it might be worth investigating if we do want to prefer
it.
Either way, you now have a file that is completely ignored, which is
going to confuse someone.
I actually think the only "fix" at the moment is to error when both are
present, since the compiler can't be sure which one is correct. So we
are stuck with at least trying to find a package file. I don't see the
speed of opening two files being a huge issue for compilation.
Anyway, if package.d is just like any other module, if we want to break
up a module, then you can keep the existing file, with the existing
module declaration, and just start moving stuff out. You wouldn't have
to literally create a package.d file, you can just keep using your
existing module.d file.
I'm sure there's a reason why it's this way, but I don't know what it
is. Anyone remember?
-Steve
