scoped imports

[Jonathan M Davis]

On Monday, August 19, 2013 04:36:37 Joseph Rushton Wakeling wrote:
> On Monday, 19 August 2013 at 01:16:44 UTC, Timothee Cour wrote:
> > goal1: avoid polluting global module name space:
> > void fun(){
> > version=A;
> > //now the code below in fun() scope has version(A) set
> > }
> > 
> > goal2:
> > void fun(){
> > version(none):
> > //all the code below this IN THIS FUNCTION becomes versioned out
> > //(avoids requiring extra {} scope
> > }
> 
> I honestly think that you are spending far too much mental effort
> in pursuit of complex, finnicky solutions for issues that can be
> dealt with much better by other means.
> 
> If you're getting namespace clashes because one set of functions
> is dependent on foo.stuff and others are dependent on bar.stuff,
> surely the simplest way to avoid it is to place them in different
> modules -- which can then be grouped into a package if needed.
> What's wrong with this approach?

I'd also chime in that version should generally be used for system stuff (like 
Posix or X86_64), and it's usually a bad idea to be setting version identifiers 
anywhere other than the command line. Version identifiers just aren't designed 
for that, particularly as setting them in a module can't affect other modules, 
seriously limiting their applicability if they're not set on the command line. 
If you have local stuff that you want to turn on or off, it's probabyl better to 
use enums, variables, is expressions, or something similar inside of static 
ifs rather than using version blocks. It's also much easier to control the 
scope of variables if want to affect the static ifs that way.

- Jonathan M Davis