Silicon Valley D Meetup - April 15, 2021 - "Compile Time Function Execution (CTFE)"

[Ola Fosheim Grøstad]

On Monday, 19 April 2021 at 06:37:03 UTC, FeepingCreature wrote:
> This is a social issue more than a technical one. The framework 
> can help, by limiting access to disk and URLs and allowing 
> tracing and hijacking, but ultimately you have to rely on code 
> to not do crazy things.

I think the downsides are conceptual and technical, not social. 
If you can implement a version counter then you get all kinds of 
problems, like first compilation succeeding, then the second 
compilation failing with no code changes. Also, you can no longer 
cache intermediate representations between compilations without a 
rather significant additional machinery. It is better to do this 
in a more functional way, so you can generate a file, but it 
isn't written to disk, it is an abstract entity during 
compilation and is turned into something concrete after 
compilation.

> to find out what works and what doesn't, and you can't gather 
> experience with what people actually want to do and how it 
> works in practice if you lock things down from the start. In

That's ok for a prototype, but not for a production language.

> Most of my annoyances with D are issues where D isn't willing 
> to take an additional step even though it would be technically 
> very feasible. No implicit conversion for user-defined types, 
> no arbitrary IO calls in CTFE, no returning AST trees from CTFE 
> functions that are automatically inserted to create macros, and 
> of course the cumbersome specialcased metaprogramming for type 
> inspection instead of just letting us pass a type object to a 
> ctfe function and calling methods on it.

So, anything that can be deduced from the input is fair game, but 
allowing arbitrary I/O is a completely different beast, 
compilation has to be idempotent. It should not be possible to 
write a program where the first compilation succeeds and the 
second compilation fails with no code changes between the 
compilation executions. Such failures should be limited to the 
build system so that you can quickly correct the problem.

IMHO, a good productive language makes debugging easier, faster 
and less frequently needed. Anything that goes against that is a 
move in the wrong direction.