Pointer semantics in CTFE

[Steven Schveighoffer]

On Wed, 30 May 2012 11:33:54 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> 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.

Unless of course, you simply always allow it, which is what I think we  
should do :)

-Steve