On 4/17/21 10:14 AM, Gavin Ray wrote:
>> [1] https://www.meetup.com/D-Lang-Silicon-Valley/events/kmqcvqyccgbtb/
>
> Ali are these recorded by chance?
We've recorded only a couple of these meetups years ago when we had
presentation-style meetups.
Although we could record these meetings, this and the last one were so
unstructured that I don't think it's worth recording. On the other hand,
I understand how they would still be valuable. Still, being on the
record would take away the candidness of these "local" meetings by a
small number of individuals.
> Now that I know will try to make it next month
I apologize for not giving advance notice but I really couldn't. :) This
is how it happened: I attended the Silicon Valley C++ meetup where Sean
Baxter presented Circle, his very powerful language based on C++:
https://github.com/seanbaxter/circle
It turns out, Circle is full of compile-time magic that we already enjoy
with D: proper compile time function execution, the equivalents of
'static if' that can inject declarations, 'static foreach' that can
inject case clauses, etc. etc.
There was so much overlap between D features and Circle that I came up
about my meetup topic during that C++ meetup and announced it at the end
of it. As always, I hoped that CTFE would just be the main theme and we
would talk about other compile-time features of D.
To my surprise, such a short-notice brought just one participant and
that was Sean Baxter himself! How fortunate I was! :) He said he had
never heard of D before and was nodding his head to most D features that
I showed. There was strong agreement with D's 'static if' (and Circle's
equivalent feature).
One big difference between D and Circle, and one that he heard many
concerns about is the fact that Circle allows file I/O at compile time.
Other than the import expression, D does not.
I heard about safety issues around allowing full I/O during compilation
but then the following points kind of convinced me:
- If I am compiling a program, my goal is to execute that program
anyway. What difference does it make whether the program's compilation
is harmful vs. the program itself.
- If we don't allow file I/O during compilation, then the build system
has to take that responsibility and can do the potential harm then anyway.
Related, the following code fails with an unfriendly error message with dmd:
int foo() {
import std.stdio;
auto file = File("some_file");
return 42;
}
pragma(msg, foo());
/usr/include/dmd/phobos/std/stdio.d(4352): Error: `fopen64` cannot be
interpreted at compile time, because it has no available source code
/usr/include/dmd/phobos/std/stdio.d(392): Error: `malloc` cannot be
interpreted at compile time, because it has no available source code
Sean thought this should be easy to fix. Well, we have to allow it to
begin with I guess.
Anyway, that's my short summary. :)
Ali
