std.experimental.allocator and @nogc

Hildigard Sandyman via Digitalmars-d digitalmars-d at puremagic.com
Sun May 8 23:22:44 PDT 2016


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 ?!


More information about the Digitalmars-d mailing list