Appender and CTFE

[Andrei Alexandrescu]

On 3/3/11 10:05 AM, Jacob Carlborg wrote:
> On 2011-03-03 16:35, Steven Schveighoffer wrote:
>> On Thu, 03 Mar 2011 10:28:00 -0500, Jacob Carlborg <doob at me.com> wrote:
>>
>>> On 2011-03-03 14:12, bearophile wrote:
>>>> Trass3r:
>>>>
>>>>> I think something should be done about this. Couldn't Appender be
>>>>> implemented without using a pointer to a struct?
>>>>
>>>> There's no need for this, there is __ctfe (that thanks to fixing bug
>>>> 4177 is usable in pure functions too), that allows to create two
>>>> paths inside the Appender, one for CT and one for runtime.
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> So much for the "having the same implementation for the compile time
>>> function and the runtime function".
>>>
>>
>> Actually, I think even if Appender wasn't implemented via pImpl style,
>> it wouldn't be available to CTFE because it uses implementation details
>> from the GC and runtime (for performance).
>>
>> I think a __ctfe thing is probably the right thing to do. Note that
>> nobody cares about append performance in CTFE because it only affects
>> compile time, not runtime, so the CTFE version can be really foolish and
>> simple, and nobody cares if it's "implemented the same".
>>
>> -Steve
>
> Yeah, but Walter and/or Andrei has mentioned that as a feature. Having
> the same code for compile time and runtime.

I see nothing wrong with the occasional forking conditioned by __ctfe. 
Even today, code may fork an optimized but nonportable implementation of 
some algorithm. The main requirement is that such forks are rare enough 
to not cause undue maintenance burden.

Andrei