On Saturday, 4 November 2017 at 11:04:33 UTC, rjframe wrote:
Many people seem to leave the module statement out of their
main.d/app.d files; I think it's a way to say "this is the main
thing - don't import it from somewhere else." Basically, it's
easier to act like that code isn't in a module than it is to
have the compiler support code not in a module.
I think maybe, the compiler should just refuse to compile
anything, unless the module namespace is explicitely stated. I
don't know what the effects of that would be in total, but it
would avoid compilation errors when, for example, you do what I
do - which is create 100's of snippets of code, save each snippet
with a name corresponding to the thing 'snipped' (so I can easily
find them again), and then discovering that they won't compile.
(i.e. D having neither a default global namespace, and then the
compiler making implicit assumptions about what namespace to use,
based on the file name, seems problematic. Better to just 'refuse
to compile' a file, unless it explicitely states a module
namespace.
e.g. (the .d files further below, without any module name
specified, will not compile - presumably because the compiler is
having problems resolving the namespace.
So why is the compiler forced to do that anyway? Why not just
refuse to compile simply because no module namespace was provided
- then a nice clear message stating that, could be provided back
to the user, instead of the cryptic message: " Error: function
expected before (), not module writeln of type void"
-----save this as writeln.d and it will not compile
-----------------
import std.stdio;
void main()
{
writeln("Hello World!");
}
-------------------------------
-----save this as to.d and it will not compile -----------------
import std.stdio;
import std.conv;
void main()
{
auto i = to!string(55);
}
----------------------------------------
