• Jacob Carlborg (31/31) Oct 31 2016 One of the big features of D and a feature that is show cased is CTFE.
• Stefan Koch (3/35) Oct 31 2016 For quick fix std.allocator has to be fitted with a if(__ctfe) to
• ketmar (17/21) Oct 31 2016 i don't remember what specs says about this situation, tbh, but

Jacob Carlborg <doob me.com> writes:

One of the big features of D and a feature that is show cased is CTFE. 
The regex module and the PEG parser generator are projects that are 
often mentioned when talking about what CTFE can do.

One of the, or _the_, major goal now for D is to reduce the dependency 
on the GC in the standard library.

These two features/goals don't mix very well together. For CTFE, 
basically the only way to allocate memory is using the GC or stack 
allocated memory.

One way to minimize the dependency on the GC is to use allocators, i.e. 
std.experimental.allocator. It's understandable that an allocator that 
uses malloc/free under the hood doesn't work at CTFE. But there's both a 
GC allocator and a stack allocator, which in theory sounds like they 
could work. One could imagine a function taking an allocator as a 
policy, using a custom well optimized allocator that will be used at 
runtime. But when the function is used at CTFE, pass in the GC allocator 
instead. Unfortunately neither the GC allocator nor the stack allocator 
work at CTFE.

Using StackFront at CTFE will give you the following error:

region.d(323,20): Error: null - null cannot be interpreted at compile 
time: cannot subtract pointers to two different memory blocks

Trying to use GCAllocator at CTFE will give you:

Error: static variable instance cannot be read at compile time

Or trying to create your own instance to bypass the above error:

memory.d(368,25): Error: gc_malloc cannot be interpreted at compile 
time, because it has no available source code

Is this something that the D core team is aware of and is planning to 
address?

Is it possible to have an allocator fulfilling the allocator interface 
at the same time works at CTFE?

-- 
/Jacob Carlborg

Stefan Koch <uplink.coder googlemail.com> writes:

On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:
 One of the big features of D and a feature that is show cased 
 is CTFE. The regex module and the PEG parser generator are 
 projects that are often mentioned when talking about what CTFE 
 can do.

 One of the, or _the_, major goal now for D is to reduce the 
 dependency on the GC in the standard library.

 These two features/goals don't mix very well together. For 
 CTFE, basically the only way to allocate memory is using the GC 
 or stack allocated memory.

 One way to minimize the dependency on the GC is to use 
 allocators, i.e. std.experimental.allocator. It's 
 understandable that an allocator that uses malloc/free under 
 the hood doesn't work at CTFE. But there's both a GC allocator 
 and a stack allocator, which in theory sounds like they could 
 work. One could imagine a function taking an allocator as a 
 policy, using a custom well optimized allocator that will be 
 used at runtime. But when the function is used at CTFE, pass in 
 the GC allocator instead. Unfortunately neither the GC 
 allocator nor the stack allocator work at CTFE.

 Using StackFront at CTFE will give you the following error:

 region.d(323,20): Error: null - null cannot be interpreted at 
 compile time: cannot subtract pointers to two different memory 
 blocks

 Trying to use GCAllocator at CTFE will give you:

 Error: static variable instance cannot be read at compile time

 Or trying to create your own instance to bypass the above error:

 memory.d(368,25): Error: gc_malloc cannot be interpreted at 
 compile time, because it has no available source code

 Is this something that the D core team is aware of and is 
 planning to address?

 Is it possible to have an allocator fulfilling the allocator 
 interface at the same time works at CTFE?

For quick fix std.allocator has to be fitted with a if(__ctfe) to 
detect usage at CTFE and use CTFEable allocation instead.

ketmar <ketmar ketmar.no-ip.org> writes:

On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:
 Using StackFront at CTFE will give you the following error:

 region.d(323,20): Error: null - null cannot be interpreted at 
 compile time: cannot subtract pointers to two different memory 
 blocks

i don't remember what specs says about this situation, tbh, but 
this is UB in C, for example. it doesn't matter that any sane 
person is ignoring it and assuming that subtracting from a 
pointer that points one cell after the region is valid, it is 
still technically unsafe operation (and possible UB).

this can be solved in two ways:

1. introducing a hack in CTFE engine, so it will explicitly allow 
using such "end-start" pointer math if result is still in the 
region at which "start" points (i'd prefer this solution)

2. fix allocators, so instead of having "_end" points past the 
allocated block, it will point right at the last cell, and do 
"+1" in each calculation (highly error-prone, as almost nobody is 
using end pointers in this way, so there will be forgotten 
increments).

allocators will break later, of course, but at least this issue 
should be fixed in CTFE engine, i think.