On Tuesday, 27 September 2016 at 13:48:39 UTC, Steven
Schveighoffer wrote:
On 9/22/16 4:16 PM, Jonathan Marler wrote:
On Thursday, 22 September 2016 at 20:09:41 UTC, Steven
Schveighoffer wrote:
Before package.d support, you could not do any importing of
packages.
You could only import modules. package.d was how the compiler
allowed
importing packages.
I don't know that there is a fundamental difference between
foo/package.d and foo.d, but this is just the solution that
was
chosen. Is it a mistake? I don't think so, it's just a
preference.
Prior to this, it was common to put "package" imports into an
"all.d"
file:
foo/all.d // import fooPart1.d fooPart2.d
foo/fooPart1.d
Ok, do you know why is this not allowed?
I'm sure if you search the forums, you can find discussions of
this. Walter probably had a reason. I'm not sure if the reason
is valid anymore now that package.d is supported.
-Steve
foo.d
foo/bar.d
I would think the reason for not supporting this is you wouldn't
want something to be a "module" and a "package" at the same time,
but introduction of the "package.d" semantics has broken that
rule.
From what I can see, it seems like the concept of "packages"
doesn't have any useful meaning anymore. Before adding
"package.d" support, a "package" was a directory/node you could
find modules underneath, but now that it can also be a module
itself, saying something is a "package" doesn't really have any
meaning. Take the following 2 cases:
Case 1: foo.d
Case 2: foo/package.d
In case 1, foo is a "module", and in case 2, foo is a "package".
The problem is that foo can behave EXACTLY THE SAME in both
cases. foo could contain typical module code, or publicly import
other modules like a typical "package.d" file, in both cases.
Saying that foo is a "package" doesn't tell you anything about
how "foo" behaves. The "package" concept seems pretty
meaningless now.
