Phobos addition formal review: std.experimental.allocator

[Dmitry Olshansky via Digitalmars-d]

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/qwatonmpnoyjsvzjpyjl@forum.dlang.org)
>>>>
>>>> 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