An article about many of the design decisions behind the Go
language. It's an excellent article even if you don't agree with
some of those decisions:
http://talks.golang.org/2012/splash.article
I suggest all people interested in language design to read that
article. Go is a simple language after all, so that page is never
hard to understand.
One group of Go design decisions is about the strictness of its
module system. One example of such strictness is that unused
imports are a compilation error! (Another example is that Go
module system does not allow cycles, and this is enforced both at
compiler and linker level.)
Recently the good Andrej Mitrovic has closed this old diagnostic
bug report of mine, marking it as dupe of another issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3972
The bug report presents a case, composed of two modules:
-------------
// File name: foo.d
module bar;
enum int x = 10;
-------------
// File name: spam.d
module test;
import foo: x;
void main() {}
-------------
After the patch by Andrej Mitrovic dmd is expected to generate a
longer and more refined error message:
spam.d(2): Error: module bar from file foo.d must be imported as
module 'bar'
Is this error message meaning that the correct spam.d is like
this?
// File name: spam.d
module test;
import bar: x;
void main() {}
But how can dmd/rdmd know the file name of the "bar" module if
it's written no where? I guess they can't, so you have to give
them the file name manually to the compiler, in some way.
I don't like all this. After almost three years since that bug
report I still think that letting D accept module names different
from their file names is a mess, it's a "flexibility" (as Walter
said in an answer) mostly useful to confuse programmers. A price
paid by everyone for few special situations.
That nice article about the Go language shows that in the long
run and for larger projects a little bit more strictness is a
better decision. Think having a large D project with 2000 or
20000 modules, where module names are randomly different from
their file names.
If that naming flexibility Walter talks about is so essential,
then I suggest to introduce a special way to get it without
allowing in the general case module names to differ from their
file names.
Bye,
bearophile
