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