On 2012-05-30 14:44:37 +0000, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
On Tue, 29 May 2012 13:35:12 -0400, Michel Fortin
<michel.for...@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.for...@michelf.com
http://michelf.com/