On Saturday, 22 August 2020 at 07:04:19 UTC, Petar Kirov
[ZombineDev] wrote:
I feel like limiting CTFE just gives a false sense of security
and destroys many interesting use cases. If a part of my build
system will do directory traversal to build the list of files
to import, what difference would it make to not have this as a
single build step. The argument that somehow
dmd -run gen_code.d | dmd -
Is more secure than just:
dmd file.d # file.d is allowed to access the FS at CT
makes no sense to me.
See Jai for example. You can run absolutely *any* code at
compile time. 5 years ago Jai's creator made a demo of running
an OpenGL game at CT [1]. In the same demo he also used CTFE to
validate calls to printf. He made the case that while many
compilers go the route of hard-coding checks for printf style
functions in the compiler, he thinks that users should be able
to implement arbitrary checks in their code. And 5 years later,
instead of D expanding the frontiers of what's possible via
CTFE, printf checking was hard coded in the compiler [2].
[1]: https://www.youtube.com/watch?v=UTqZNujQOlA
[2]: https://github.com/dlang/dmd/pull/10812/files
I don't need say that unlimited CTFE has been a huge success
for Jai. What I wish is that we can learn from this stop
bringing arguments that C people would bring for D's CTFE ("My
Makefile calls a Python script to generate C code and it's
doing just fine, so I don't think one should be allowed to run
code at compile time, as it will make the code just harder to
follow").
As another example, types in Zig are first class citizens [3]
and can be manipulated with CTFE just like any other value.
"Type functions" in D should just be regular D functions taking
types as parameters and returning types.
[3]:
https://ziglang.org/documentation/master/#Introducing-the-Compile-Time-Concept
Strongly Agreed!
