Am 23.06.2015 um 18:53 schrieb extrawurst:
> 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
>
> I simply quote his following post in the mentioned thread:
>
> "The biggest benefit of breaking up the big modules is so you can access
> some of it without requiring all of it. But when the part you want is in
> the package.d, you can't get it independently anymore; importing that
> also imports everything else, negating the reason it was split up in the
> first place."

Not to mention https://issues.dlang.org/show_bug.cgi?id=11847

On 6/23/15 9:53 AM, extrawurst 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
>
> I simply quote his following post in the mentioned thread:
>
> "The biggest benefit of breaking up the big modules is so you can access
> some of it without requiring all of it. But when the part you want is in
> the package.d, you can't get it independently anymore; importing that
> also imports everything else, negating the reason it was split up in the
> first place."

But that doesn't apply to packages that do NOT originate as big modules, so they have no backward compatibility issue. This is the case for std.allocator. I see a net pessimization for everyone involved to change the current packaging.

All I'm saying is we shouldn't take it noncritically that packages should be done one particular way.


Andrei

On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
> But that doesn't apply to packages that do NOT originate as big modules, so they have no backward compatibility issue.

My thought isn't really about backward compatibility but about minimizing dependencies with sibling modules.

I don't want to repeat my argument too much from the other thread, but imagine you're writing a minimalist library that is meant to interact with other minimalist libraries. To interact, you want a shared interface and basic types. But to be minimalist, you want to pull as little other standard code as possible.


The typical user might just import std.whatever and get it all available. But this minimalist user only wants std.whatever.basic_interface. If the basic interface is shoved inside package.d, she can't get get to it without inadvertently pulling in more modules too. This can quickly grow into a web of dependencies where importing just an interface definition ends up grabbing dozens if implementations you don't want too, bloating compile times and binary sizes.

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.

On 6/23/15 10:15 AM, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
>> But that doesn't apply to packages that do NOT originate as big
>> modules, so they have no backward compatibility issue.
>
> My thought isn't really about backward compatibility but about
> minimizing dependencies with sibling modules.
>
> I don't want to repeat my argument too much from the other thread, but
> imagine you're writing a minimalist library that is meant to interact
> with other minimalist libraries. To interact, you want a shared
> interface and basic types. But to be minimalist, you want to pull as
> little other standard code as possible.
>
>
> The typical user might just import std.whatever and get it all
> available. But this minimalist user only wants
> std.whatever.basic_interface. If the basic interface is shoved inside
> package.d, she can't get get to it without inadvertently pulling in more
> modules too. This can quickly grow into a web of dependencies where
> importing just an interface definition ends up grabbing dozens if
> implementations you don't want too, bloating compile times and binary
> sizes.

The case with std.allocator is not everything is imported in it, so no bloating no nothing. -- Andrei

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

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.

On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
> 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 agree, a minimalist package.d seems utterly pointless to me.

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

On 6/23/15 2:12 PM, Dicebot wrote:
> 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? :)

There is functionality in std.allocator to get anyone started who doesn't want to sit down and define their own allocator.

People who want to do that can import std.allocator.building_blocks which is a package fully including all that's needed.

> 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 afraid of creating precedent if that's the best way to go. Again: I have the impression we're blocked into an assumption we didn't take critically until now.


Andrei