It seems to me, that std.experimental.allocator should work with @nogc annotated functions if none of the allocators being used are the gcallocator, though it's not at all clear to me how this would work.

Are there plans for this?

On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
> It seems to me, that std.experimental.allocator should work with @nogc
> annotated functions if none of the allocators being used are the
> gcallocator, though it's not at all clear to me how this would work.
>
> Are there plans for this?

If only we had @assumenogc ala @safe's @trusted but for @nogc we could definitely do it then.

On Monday, 9 May 2016 at 04:50:59 UTC, Danni Coy wrote:
> It seems to me, that std.experimental.allocator should work with @nogc annotated functions if none of the allocators being used are the gcallocator, though it's not at all clear to me how this would work.
>
> Are there plans for this?

It already mostly works in @nogc block:
- Mallocator and AlignedMallocator are @nogc.
- make() dispose(), shrinkArray(), etc are templatized function so they infer @nogc.
- higher level blocks also infer @nogc.

example:
----
import std.experimental.allocator;
import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.free_list;

struct Foo{}

void main(string[] args) @nogc
{
    Foo* foo = Mallocator.instance.make!Foo;
    Mallocator.instance.dispose(foo);
    uint[] arr;
    arr = Mallocator.instance.makeArray!uint(8);
    Mallocator.instance.shrinkArray(arr,1);
    Mallocator.instance.dispose(arr);
    FreeList!(Mallocator,0,size_t.sizeof) fl;
    auto p = fl.allocate(8);
    fl.deallocate(p);
}
----

Initially it was not the case but it's been done latest months, e.g in this PR:
https://github.com/dlang/phobos/pull/3856

On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
> On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
>> It seems to me, that std.experimental.allocator should work with @nogc
>> annotated functions if none of the allocators being used are the
>> gcallocator, though it's not at all clear to me how this would work.
>>
>> Are there plans for this?
>
> If only we had @assumenogc ala @safe's @trusted but for @nogc we could definitely do it then.

I think you've been misleaded by the initial Q that spuriously assumes that allocators are not @nogc but @nogc allocators seems to be a milestone that's in our back now.

On 09/05/2016 5:16 PM, Hildigard Sandyman wrote:
> On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
>> On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
>>> It seems to me, that std.experimental.allocator should work with @nogc
>>> annotated functions if none of the allocators being used are the
>>> gcallocator, though it's not at all clear to me how this would work.
>>>
>>> Are there plans for this?
>>
>> If only we had @assumenogc ala @safe's @trusted but for @nogc we could
>> definitely do it then.
>
> I think you've been misleaded by the initial Q that spuriously assumes
> that allocators are not @nogc but @nogc allocators seems to be a
> milestone that's in our back now.

All I know is that until IAllocator can be @nogc, we can't use theAllocator + processAllocator. Which kinda requires @assumenogc for the GC allocator.

On Monday, 9 May 2016 at 05:27:24 UTC, rikki cattermole wrote:
> On 09/05/2016 5:16 PM, Hildigard Sandyman wrote:
>> On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
>>> On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
>>>> It seems to me, that std.experimental.allocator should work with @nogc
>>>> annotated functions if none of the allocators being used are the
>>>> gcallocator, though it's not at all clear to me how this would work.
>>>>
>>>> Are there plans for this?
>>>
>>> If only we had @assumenogc ala @safe's @trusted but for @nogc we could
>>> definitely do it then.
>>
>> I think you've been misleaded by the initial Q that spuriously assumes
>> that allocators are not @nogc but @nogc allocators seems to be a
>> milestone that's in our back now.
>
> All I know is that until IAllocator can be @nogc, we can't use theAllocator + processAllocator. Which kinda requires @assumenogc for the GC allocator.

It's true but... why do you bother with IAllocator ? Everything can be set a compile time with a template parameter. As long as the param is a struct with allocate/deallocate/reallocate it's OK. you can use already a good part of the package content in a @nogc fashion.

Do you have an example where IAllocator must be used and where, for example, Mallocator can't be passed ?!

On 09/05/2016 6:22 PM, Hildigard Sandyman wrote:
> It's true but... why do you bother with IAllocator ? Everything can be
> set a compile time with a template parameter. As long as the param is a
> struct with allocate/deallocate/reallocate it's OK. you can use already
> a good part of the package content in a @nogc fashion.
>
> Do you have an example where IAllocator must be used and where, for
> example, Mallocator can't be passed ?!

The moment where you need to use OOP, you most definitely need IAllocator.
I cannot make a windowing library without the use of IAllocator.

You can't always template functions with the type that is the allocator.
Its just not possible or reasonable.

On Mon, May 9, 2016 at 3:10 PM, Hildigard Sandyman via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 9 May 2016 at 04:50:59 UTC, Danni Coy wrote:

> It already mostly works in @nogc block:
> - Mallocator and AlignedMallocator are @nogc.

I was trying to use BitmappedBlock, AllocatorList and MmapAllocator
with @nogc without much luck.
BitmappedBlock and AllocatorList, both take allocators as arguments so
they may or may not use GC depending on which allocators they are
using. I was wondering how D would handle this.

> It's true but... why do you bother with IAllocator ? Everything can be set a compile time with a template parameter. As long as the param is a struct with allocate/deallocate/reallocate it's OK. you can use already a good part of the package content in a @nogc fashion.
>
> Do you have an example where IAllocator must be used and where, for example, Mallocator can't be passed ?!

How is that going to work in a situation where the code is in a library that you are linking to rather than compiling?

On Monday, 9 May 2016 at 06:35:36 UTC, rikki cattermole wrote:
> On 09/05/2016 6:22 PM, Hildigard Sandyman wrote:
>> It's true but... why do you bother with IAllocator ? Everything can be
>> set a compile time with a template parameter. As long as the param is a
>> struct with allocate/deallocate/reallocate it's OK. you can use already
>> a good part of the package content in a @nogc fashion.
>>
>> Do you have an example where IAllocator must be used and where, for
>> example, Mallocator can't be passed ?!
>
> The moment where you need to use OOP, you most definitely need IAllocator.
> I cannot make a windowing library without the use of IAllocator.
>
> You can't always template functions with the type that is the allocator.
> Its just not possible or reasonable.

Yes there's a problem with this but that doesn't mean that whole package is concerned. The first message clearly orientates the answer:

> It seems to me, that std.experimental.allocator should work with @nogc
It should == It doesn't yet

> Are there plans for this ?
Question is based on the previous wrong assumption, but since the most important part of the message is the Q itself, it makes people swallow the craps.

So basically anyone not well informed who reads this can deduce that it doesn't work at all.