Bug 357 – D keywords in import/module are (unnecessary) forbidden

It is a quite a big shortcoming: you can not have e.g. 'interface' directory in your project file structure. D keyword should be allowed in import/module declarations as it (probably) don't make unnecessary ambiguities.

Allowing this would wreak havoc on fully qualified names. Either those would effectively be disallowed for those modules or the restrictions that identifiers can't contain keywords would have to be lifted. The latter solution would definitely create ambiguities. Think of the following code, for example: import alias; // ... some more code ... alias.foo bar; Does this declare a variable bar of type alias.foo, or does this create an alias bar for an identifier foo in the top-level namespace? This is a bad idea. Either inconsistencies or ambiguities will be introduced if this change is made.

Clean separation between keywords and identifiers minimizes parsing ambiguities and all sorts of confusion.

When after discussion I (almost*) completely agree with arguments I would just request to add single sentence to documentation about requirement that module names and file names can not be D keyword. It is very important design decision and should be documented. *Almost, because it seems that only first part of module name could make problems. e.g. dbase.interface seems to be ok.

... of course probably best solution would be to have 'keyword escape character' like e.g. @ In such a way you could declare following module: module @this.@is.@interface.@module; :-) Current state gives impression that D imposes really big restrictions on what is possible to do with the language: you can not use arbitrary directories and/or filenames when organizing your project.

Although the grammar for the packages says they are Identifiers which implicitly excludes them being keywords, I'll clarify the documentation on that point. Otherwise, it is working as designed. I agree you cannot use arbitrary names for module file names - the names must be valid D identifiers. While a restriction, I don't think it is onerous or overly restrictive. You can put modules in arbitrarily named directories, but those directories cannot then be used as package names. Package names must correspond to D identifiers. I don't think there is enough benefit to changing this to justify the cost.