On Saturday, March 31, 2012 17:30:36 Timon Gehr wrote: > On 03/31/2012 03:49 PM, Martin Nowak wrote: > > On Sat, 31 Mar 2012 13:06:36 +0200, Timon Gehr <timon.g...@gmx.ch> wrote: > >> On 03/30/2012 11:35 PM, Jonathan M Davis wrote: > >>> But personally, I like the idea of making it so that publicly > >>> imported symbols > >>> can be accessed as if they were in the module that publicly imported > >>> them > >> > >> +1. That is even better than treating the package module specially. > > > > That already works, doesn't it? > > It already works indeed. My bad.
Does it? I thought that std.range.replace wouldn't work (even though std.range publicly imports std.array), because replace isn't part of std.range. You don't need to import std.array if you import std.range, because std.range does, but you can't specificy it's path as if it were in std.range. I'll have to check... Okay. You're right. std.range.replace _does_ work. So then the only issue is making it so that public imports in std.datetime.package are treated as if they were in std.datetime. That seems like the cleanest solution to me. It goes along quite nicely with making it so that anything in std.datetime.package is imported when importing std.datetime. - Jonathan M Davis
