On Thursday, April 12, 2012 14:30:50 Xan wrote: > But it's a messy limitation. Why we should have it? For C++ > compatibilities?
Messy? How so? You can't put any characters in a module name which aren't valid identifiers. So what? Just name your module differently. Is your complaint that you can't just rename your cpp-file.cpp to cpp-file.d, make a few tweaks to its contents, and then have it compile as D? If that's the case, the file name is the least of your concerns. And I don't know why else you'd care about any "compatability" with C++ due to file names. How D interacts with C/C++ has nothing to do with the file names of either. Module names can end up being used inside code to fully qualify symbol names. e.g. std.algorithm.sort(arr); If you could put characters in a module name which weren't valid in an identifier, this would cause serious issues for the lexer and parser. std.algo-rithm.sort(arr); So, it's a very reasonable restriction that a module name be required to be a valid identifier. And this is not unusal among programming languages with module systems. C/C++ doesn't have such restrictions, because they had the misfortune to choose the whole #include mess. Their choice is p probably due - at least in part - to computing restrictions at the time which would have made putting all of the symbols in memory too expensive, so as bad as it is, they probably didn't have much choice, but it still has horrible problems - some of which are listed here: http://www.drdobbs.com/blogs/cpp/228701711 D's modules are _far_ better, even if with their restrictions on file names. - Jonathan M Davis
