On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu wrote:
>> 2. `IAllocator` is defined inside `package.d` file. That means that it
>> is impossible to use interface without import ALL of allocator modules
>
> Fixed, now interested users need to import std.experimental.allocator.building_blocks.
>
>> 3. Same concern is about
>> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/package.d#L218-L228
>> - unless you actually import all stuff via package.d, those configured
>> allocators are not available.
>
> Fixed per above.

Is it? I still see those symbols defined in package.d , 14ccc3a02f3dd332cb435abaf3c35cb8847797c0 does not seem to have affected that.

On 6/22/15 2:40 PM, Dicebot wrote:
> On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu wrote:
>>> 2. `IAllocator` is defined inside `package.d` file. That means that it
>>> is impossible to use interface without import ALL of allocator modules
>>
>> Fixed, now interested users need to import
>> std.experimental.allocator.building_blocks.
>>
>>> 3. Same concern is about
>>> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/package.d#L218-L228
>>>
>>> - unless you actually import all stuff via package.d, those configured
>>> allocators are not available.
>>
>> Fixed per above.
>
> Is it? I still see those symbols defined in package.d ,
> 14ccc3a02f3dd332cb435abaf3c35cb8847797c0 does not seem to have affected
> that.

Perhaps I misunderstood the request - currently the imports in allocator/package.d are:

public import std.experimental.allocator.common,
    std.experimental.allocator.typed;
import std.algorithm, std.conv, std.exception, std.range, std.traits,
    std.typecons, std.typetuple;
version(unittest) import std.random, std.stdio;

Is that okay, and if not what should change?


Andrei

On 6/21/15 4:47 AM, Dicebot wrote:
> 5.
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_stats_collector.html
> has no overview documentation at all

https://github.com/D-Programming-Language/phobos/commit/ef6de891197db6d497df11c9350781eef38df196


Andrei

On 6/21/15 4:47 AM, Dicebot wrote:
> 6. Usage of ternary is not always clear / justified. In `IAllocator` it
> is explained and makes sense but there are things like
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_bitmapped_block.html
> ("Ternary empty() - Returns true iff no memory is currently allocated
> with this allocator"). I am still not sure why it is used there instead
> of simple boolean.

Founds a bunch of issues with the docs indeed; switching the static interface from bool to Ternary (for the sake of unification with IAllocator) was a last-minute thing.

https://github.com/D-Programming-Language/phobos/commit/16f5a5631cf1f2eeea3779785c3ea17682b8ff45


Andrei

On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote:
> Perhaps I misunderstood the request - currently the imports in allocator/package.d are:
>
> public import std.experimental.allocator.common,
>     std.experimental.allocator.typed;
> import std.algorithm, std.conv, std.exception, std.range, std.traits,
>     std.typecons, std.typetuple;
> version(unittest) import std.random, std.stdio;
>
> Is that okay, and if not what should change?

My concern was about the fact that symbols `IAllocator`, `theAllocator`, `processAllocator` and bunch of others are defined within `package.d` itself and not provided via public import. That means that anyone willing to change default allocator or use `make` MUST import all std.allocator modules even if nothing else is really needed (those utilities look very independent). Which means processing bunch of unnecessary imports - and more of those if more modules will get added to the package.

I'd prefer to have a small dedicated module, i.e. `std.allocator.api` (not going to discuss names!) and do public import of it from `std.allocator.package.d`. Makes sense?

On 6/23/15 2:18 AM, Dicebot wrote:
> On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote:
>> Perhaps I misunderstood the request - currently the imports in
>> allocator/package.d are:
>>
>> public import std.experimental.allocator.common,
>> std.experimental.allocator.typed; import std.algorithm, std.conv,
>> std.exception, std.range, std.traits, std.typecons, std.typetuple;
>> version(unittest) import std.random, std.stdio;
>>
>> Is that okay, and if not what should change?
>
> My concern was about the fact that symbols `IAllocator`,
> `theAllocator`, `processAllocator` and bunch of others are defined
> within `package.d` itself and not provided via public import. That
> means that anyone willing to change default allocator or use `make`
> MUST import all std.allocator modules even if nothing else is really
> needed (those utilities look very independent). Which means
> processing bunch of unnecessary imports - and more of those if more
> modules will get added to the package.
>
> I'd prefer to have a small dedicated module, i.e. `std.allocator.api`
>  (not going to discuss names!) and do public import of it from
> `std.allocator.package.d`. Makes sense?

I see. Well this raises the question whether importing std.xyz
automatically means everything under std.xyz is transitorily imported. Right now it's not - the more advanced/obscure building blocks are not automatically imported if you just import std.allocator; for those you'd need to import the std.allocator.building_blocks package, or individual modules from it like std.allocator.building_blocks.region.

This idea was proposed by Mike on 2015/05/18:

> Would it be better to move the porcelain code into package.d so the
> nomenclature simply becomes `import std.allocator;`?

I liked the idea that someone who's not an expert goes "let me import std.allocator and call it a day" whereas someone who wants to tweak, customize, etc. they'd need to be more specific.

If we define an entry point such as "std.allocator.api", novices will have one more thing to remember, or some will still import "std.allocator" thus pulling everything without realizing it.

So I'd say let's keep simple things simple. If you want to allocate, import std.allocator.


Andrei

On 6/23/15 8:56 AM, Andrei Alexandrescu wrote:
> I see. Well this raises the question whether importing std.xyz
> automatically means everything under std.xyz is transitorily imported.

s/transitorily/transitively/

On Tuesday, 23 June 2015 at 15:56:15 UTC, Andrei Alexandrescu wrote:
> On 6/23/15 2:18 AM, Dicebot wrote:
>> On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote:
>>> Perhaps I misunderstood the request - currently the imports in
>>> allocator/package.d are:
>>>
>>> public import std.experimental.allocator.common,
>>> std.experimental.allocator.typed; import std.algorithm, std.conv,
>>> std.exception, std.range, std.traits, std.typecons, std.typetuple;
>>> version(unittest) import std.random, std.stdio;
>>>
>>> Is that okay, and if not what should change?
>>
>> My concern was about the fact that symbols `IAllocator`,
>> `theAllocator`, `processAllocator` and bunch of others are defined
>> within `package.d` itself and not provided via public import. That
>> means that anyone willing to change default allocator or use `make`
>> MUST import all std.allocator modules even if nothing else is really
>> needed (those utilities look very independent). Which means
>> processing bunch of unnecessary imports - and more of those if more
>> modules will get added to the package.
>>
>> I'd prefer to have a small dedicated module, i.e. `std.allocator.api`
>>  (not going to discuss names!) and do public import of it from
>> `std.allocator.package.d`. Makes sense?
>
> I see. Well this raises the question whether importing std.xyz
> automatically means everything under std.xyz is transitorily imported. Right now it's not - the more advanced/obscure building blocks are not automatically imported if you just import std.allocator; for those you'd need to import the std.allocator.building_blocks package, or individual modules from it like std.allocator.building_blocks.region.
>
> This idea was proposed by Mike on 2015/05/18:
>
>> Would it be better to move the porcelain code into package.d so the
>> nomenclature simply becomes `import std.allocator;`?
>
> I liked the idea that someone who's not an expert goes "let me import std.allocator and call it a day" whereas someone who wants to tweak, customize, etc. they'd need to be more specific.
>
> If we define an entry point such as "std.allocator.api", novices will have one more thing to remember, or some will still import "std.allocator" thus pulling everything without realizing it.
>
> So I'd say let's keep simple things simple. If you want to allocate, import std.allocator.
>
>
> Andrei

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)

for convenience the package.d could still import a bunch of default stuff publicly for the "normal" user.

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

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."