On 24-Jun-2015 00:12, Dicebot wrote:
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu wrote:
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.org/post/[email protected])
What is the rationale? -- Andrei
My reasoning is simple : when `package.d` only contains public imports
it allows to both use simple `import std.allocator` for those who want
to get started quickly and pick only necessary imports for those who try
optimizing build times / code clarity. Not doing that does not change
anything for those who prefer `import std.allocator` but makes fine
tuning of imports impossible. Thus former approach looks either equal or
superior for all use cases.
The "import std.allocator" is already minimal - only contains the high
level stuff. -- Andrei
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
If anything, that will be the first package.d in Phobos (AFAIK) which
won't feature public import of _all_ package modules.
I'm not sure if that's the case with std.allocator but importing package
IMHO should import _typical_ set of submodules.
Things that are more niche and rare (power user oriented) shouldn't
really be in package.d
--
Dmitry Olshansky
