import syntax

[Chris Nicholson-Sauls]

Karl Bochert wrote:
> Is there some reason why the syntax is 
> import std.c.stdio
> Rather than 
> import std\c\stdio
> 
> The dot syntax prevents the use of relative paths to modules ( I'm guessing -- I
> haven't actually tried 'import ......foo;' )
> 
> Are relative paths considered bad for imports?
> Is this just an unfortunate side-effect of a syntax that has other advantages?
> 
> I guess the work-around is to use the -I compiler switch which seems like a
> terrible approach to me, moving information that should be in the source to the
> makefile.
> 

Except that I haven't touched a makefile in ages.  Check out the Build utility:
http://www.dsource.org/projects/build

All I usually ever run anymore is one of 'build @debug', 'build @doc', or 'build @release'.

As to the use of the dot in imports, the reason is simple: you are /not/ importing a path, 
but rather a module which may or may not belong to a package.  For example, so I have a 
module 'array' in package 'utils'.  Say that I have package 'utils' stored with some other 
code in the subdirectory 'lib'.  My module 'array' has declared itself 'module 
utils.array;' ... so I can only import it as 'import utils.array;'.  The location of that 
package in the filesystem is meaningless to my program, only the relative location of the 
modules within their packages (if any) has any meaning.  However, the compiler needs to 
know where to look for packages and modules, so I need to pass '-Ilib' on the command 
line, or in my Build Response File.

-- Chris Nicholson-Sauls