phobos dependencies

[captaindet]

On 2013-12-20 11:38, H. S. Teoh wrote:
> On Fri, Dec 20, 2013 at 09:27:55AM -0800, Andrei Alexandrescu wrote:
>> On 12/20/13 5:45 AM, Joseph Rushton Wakeling wrote:
>>> On 20/12/13 10:06, Meta wrote:
>>>      void topN(alias less = "a<  b",
>>>              SwapStrategy ss = SwapStrategy.unstable,
>>>              Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
>>>          if (isRandomAccessRange!(Range)&&  hasLength!Range
>>>              &&  isUniformRNG!RandomGen)  //<--- needs
>>> std.random.isUniformRNG
>>>      {
>>>          static assert(ss == SwapStrategy.unstable,
>>>                  "Stable topN not yet implemented");
>>>          while (r.length>  nth)
>>>          {
>>>              auto pivot = uniform(0, r.length, rng);
>>>              // ... etc. ...
>>>          }
>>>      }
>>
>> I had this idea fot a while, and Walter is favorable of it as well -
>> extend "import" for one-shot use. With that feature the example
>> would become:
>>
>>      void topN(alias less = "a<  b",
>>              SwapStrategy ss = SwapStrategy.unstable,
>>              Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
>>          if (isRandomAccessRange!(Range)&&  hasLength!Range
>>              &&  import.std.random.isUniformRNG!RandomGen)
>>      { ... }
>>
>> In this case "import" would syntactically be placed at the beginning
>> of a qualified name, meaning "import this module lazily and look up
>> the symbol in it".
> [...]
>
> Hmm. Why do we need to incorporate the 'import' keyword in the first
> place? What about extending symbol lookup, so that if a fully-qualified
> symbol x.y.z can't be found in the current symbol tables, and x/y exists
> in the current import path, then implicitly try to import x.y and lookup
> z in that module. Then you could just write:
>
> 	void f(T)(T t) if (std.range.isInputRange!T) ...
>
> and the compiler will automatically import std.range within that scope.
> Obviously, it's a bad idea to import std.range into module scope, since
> it would pollute the module namespace, but it seems a good idea to do a
> one-shot import automatically, since the qualified symbol itself already
> says which module the symbol is supposed to be defined in. There's no
> need to add another "import." prefix to it, IMO.
>
>
> T

one could make it a bit more explicit by requiring

	import std;

at module level, or even more explicit

	auto import std;

to enable lazy import of everything that is hierarchically below. could then be used for user libraries as well:

	import mybreadandbutter;		// has several sub folders / packages

/det