CTFE ^^ (pow)

[Nick Sabalausky (Abscissa)]

On 03/24/2018 12:37 PM, Manu wrote:
> 
> I understand table generation, that is the standard approach. It's

Huh? Then I guess I don't understand why you implied that the 
alternative to CTFE was manually regenerating and copy-pasting tables:

 >> On 3/23/2018 11:09 AM, Manu wrote:
 >>> Like, in this particular project, being able to generate all tables at
 >>> compile time is the thing that distinguishes the D code from the C++
 >>> code; it's the *whole point*... If I have to continue to generate
 >>> tables offline and paste big tables of data in the source code (and
 >>> then re-generate them manually when I change something);


> I'm not sure why I seem to have to defend the idea that it's a *great
> thing* that D (in theory; according to the advertising brochure) does
> away with these requirements.

No need to defend it, we're all sold on it already. To clarify: I wasn't 
saying "no need for CTFE", I was saying: "If you *have* to work around 
an unfortunate CTFE limitation, like the missing x^^y, then it's not 
hard to do so *without* all that manual work you suggested".


 > made awkward by the fact that build systems are hard,

The decent ones aren't. (And if you happen to be stuck with MSBuild, 
well, then my sincere condolences. I periodically use Unity3D and I wish 
soooo much it wasn't tied to MSBuild...or CLR for that matter, but I 
digress...frequently ;))

Frankly, if a buildsystem makes doing XYZ (ex: "executing a CLI command 
upon build") harder than it would be in a shellscript, then the given 
buildsystem sucks and you may as well replace it with a plain old script.


 > and a user of a lib with such build requirement inherits that baggage
 > into their project.

Meh, its about half an ounce of baggage for the user. (But again, yes, 
CTFE is still better...at least when it doesn't slow down their build 
too much). And its zero-baggage if the generated files aren't dependent 
on the user's code, though I see now (below) that's not the case for 
your project.


> It just occurred to me too that it's not even that simple. The
> instantiation sites (which are in user code) dictate what tables need
> to be emit. It's not feasible to generate all possible tables...
> there's a combinatorial explosion of possible inputs. I instantiate
> only what tables the user needs on demand. It's impossible to
> pre-generate 'all' tables; there's no such quantity.

I guess that does complicate it somewhat (and again, to be clear, being 
able to just do CTFE would obviously be far better than this) but FWIW, 
that still might not be difficult to overcome, depending on the exact 
nature of the problem: Whatever inputs are necessary for table 
generation, let the user specify them as cmdline args to your generator 
tool. Again, not ideal, but a perfectly feasible workaround in a pinch, 
and doesn't require abandoning all the *other* benefits of D.