About Go, D module naming

bearophile bearophileHUGS at lycos.com
Thu Dec 20 17:24:58 PST 2012


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


More information about the Digitalmars-d mailing list