On Wed, 30 May 2012 11:33:54 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
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.
Unless of course, you simply always allow it, which is what I think we
should do :)
-Steve
