Pointer semantics in CTFE

[Michel Fortin]

On 2012-05-30 14:44:37 +0000, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> Personally, I think it'd be much cleaner to go with some kind of magic  
>> function than trying to match the condition against a predefined  
>> pattern. Something like da.isSliceOf(a), which could do the usual  
>> pointer thing at runtime and call some sort of CTFE intrinsic at  
>> compile-time.
> 
> That doesn't help when most code does not use this today.  I.e. one of 
> the  main benefits of ctfe is that you don't *have* to write special 
> code.

But at the other end, there should be an easy to understand separation 
between what is supported by CTFE and what is not. Once you try to add 
special cases for some code patterns by adding heuristics, those 
heuristics now define the line and would have to become part of the 
language specification.

More generally, the drawback of this kind of pattern recognition is 
that there's an infinite pool of equivalent patterns to recognize, and 
seemingly innocuous changes to a CTFEable function could break its 
CTFEablility if they happen to cross the invisible boundary.

I'm just trying to point out the drawbacks of too clever heuristics. If 
such an heuristic is used, I think it should be limited in scope and 
well documented. Unfortunately, that means you'll still have to care 
about writing code in a way that fits the documented pattern. It'd be 
much easier to reason about CTFEability if the pattern had to be 
encapsulated in its own function.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/