CTFE vs. traditional metaprogramming

[Don]

Yigal Chripun wrote:
> On 12/10/2009 18:45, BCS wrote:
>> Hello Michel,
>>
>>> On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> said:
>>>
>>>> Thanks!
>>>>
>>>> I plan to add more text at the end of the chapter that discusses the
>>>> opportunities of CTFE. Walter revealed to me that CTFE, particularly
>>>> now after it's been improved by leaps and bounds by Don and by Walter
>>>> himself, could obviate a lot of the traditional metaprogramming
>>>> techniques developed for C++.
>>>>
>>>> One question that bugs me is, where do you draw the line? Say there's
>>>> a metaprogramming problem at hand. How to decide on solving it with
>>>> CTFE vs. solving it with templates? It would be great to have a
>>>> simple guideline that puts in contrast the pluses and minuses of the
>>>> two approaches.
>>>>
>>>> It is quite possible that templates get relegated to parameterized
>>>> functions and types, whereas all heavy lifting in metaprogramming
>>>> should be carried with CTFE.
>>>>
>>> My idea on templates is that they're good when you have type
>>> parameters, or to create types based on constant parameters.
>>>
>>> - - -
>>>
>>> But an interesting thing I realized in the last few months is this:
>>> all you can do with a template you can also do at runtime provided
>>> sufficient runtime reflection capabilities. Even creating types!
>>> Details follow.
>>>
>>
>> I'd like to forward the thought that runtime reflection and type
>> creation is NOT a replacement for the same at compile time just as the
>> compile time version is not a replacement for the run time version.
>>
>> Just to pick two differences: errors are forced to runtime and runtime
>> types can't be inlined.
>>
>>
> 
> you can have compile-time errors with (static) asserts and you can 
> inline runtime types by way of a smart JITer/VM and run-time profiling.

CTFE will get exceptions. Shin already put a patch in Bugzilla to do it 
in a few special case; it's not included yet, since the intention is for 
CTFE to support classes, and hence should support general exceptions.

OTOH, I think BCS was contrasting detecting errors during development 
(at compile-time) instead of during deployment (at run-time).