How about Go's... error on unused imports?

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:hdklbg$2p2f$1 at digitalmars.com...
> "bearophile" <bearophileHUGS at lycos.com> wrote in message 
> news:hdkavm$1b0k$1 at digitalmars.com...
>> Clay Smith:
>>
>>>I would like my all.d files to not give errors :o<
>>
>> "all.d" files are a hack used to patch one of the minor holes of the 
>> current D module system. The right way to do that is with a syntax like 
>> (that must not import the 'foo' name too in the current namespace, only 
>> the names inside "std.foo"):
>>
>> import std.foo: *;
>>
>> Every part of a language needs to be designed with care. Approximate 
>> designs with several holes aren't enough.
>>
>
> I used to think so, but I'm not so sure anymore. In my Goldie project, one 
> of the modules ("goldie.file") is something with a whole lot of types and 
> details about loading a .cgt file. In the vast majority of use-cases, the 
> Goldie library user has no reason to use any of those directly, so as 
> useful as "goldie.all" is, it would be pointless for me to include that 
> "goldie.file" in "goldie.all", which is exactly what "goldie.*" would do 
> automatically if it existed. Now, certainly, I could just mark everything 
> in "goldie.file" as private, but I do want people to be able to import and 
> use it directly if they want to (Ex, if they want to use Goldie as a 
> springboard for their own .cgt-file handling routines).
>
> Plus, I'll often have renamed and deliberately unused source files in the 
> same directory as "real" modules, and I wouldn't want them automatically 
> grabbed by ".*". I suppose I could change their extension, but then the 
> editor would get confused, and I'd have to work around that, etc...

Another Goldie-derived example of ".all" being more useful than ".*": I'm 
building a tool that generates a statically-compiled and linked D source 
version of a grammar (normally they're loaded at runtime from a file). 
Unless I change my mind, I intend for these to be used with "import somelang 
= myapp.staticlangs.somelang.all", so that multiple static langauges can be 
used together (Ie, "d.Token", "haxe.Token", "js.Token", whatever). I 
originally had the generation tool give unique names to each type (Ie, 
"Token_haxe", "Token_js", etc), but I'm thinking now the renamed import 
approach is probably more appropriate and less hack-ish, and comes with more 
built-in flexibility.

But anyway, suppose someone has a project with multiple languages like this 
(ex "myapp.staticlangs.haxe.all" and "myapp.staticlangs.js.all", and maybe a 
couple others). If they tried an "import myapp.staticlangs.*" approach, that 
just wouldn't work, because they're designed to be used as renamed imports. 
But they could easily create a "myapp.staticlangs.all" (or hell, I could 
even generate one) that would automatically do the correct renamed imports. 
Anyway, just another thing that ".*" importing can't really handle.