They came up quite short on content this year, but the format is significantly improved over previous iterations, so I was happy to see that.
Safe by default was listed in the interviews as a priority for upstream's editions thing. The last blog here was about safe in OpenD and we're probably going to take different directions, since we're not going down the editions route. Unsure though, it will take a little time for either of us to make it work and we'll want to keep an eye on what solutions upstream find (and I suspect they'll keep an eye on us too).
Atila complained again that his work loop is too slow. He laid out a dream where the compiler automatically does the bare minimum work to give the feedback he wants while working.
Of course, I tend to argue that you can make code compile much faster with small changes in a lot of cases. My code compiles over 10x faster than his code, for example. I've written about many of these techniques in the past.
But it occurred to me while he talked this time that we're actually not that far from his goal of test-driven development feedback cycles being quick, for practical purposes at least: we can use the CTFE engine to interpret a unittest and bypass other work.
I did a proof-of-concept live on the chat.
bool ctfeTestRunner() { import MODULE_WITH_TESTS; foreach(test; __traits(getUnitTests, MODULE_WITH_TESTS)) //static if(__traits(compiles, { enum x = { test(); return 0; }(); })) try { test(); pragma(msg, "here"); } catch(Throwable t) { return false; } return true; } static assert(ctfeTestRunner());
That is, put the tests in a CTFE scaffold and static assert that they didn't runtime assert in ctfe. If you have local imports, untested functions don't even process imports (note you do NOT use dmd -i here, but rather dmd -o- to suppress codegen and linking - all you're interested in is a limited CTFE result.
This gave me a pass/fail response in 18 milliseconds on a sample file. 600 ms on a larger application, so the quickness disappeared fast using a stock upstream compiler... but...
OpenD has a couple advantages over upstream! We have an experimental feature for named unit tests built into the language. We could make a selective test runner using the ctfe engine. More to come on this in the future, I definitely think there's some potential here and a quicker test cycle is always appreciated.
Robert argued that dropping the safe requirement for non-gc containers is worthwhile. I probably agree, but otherwise have few remarks except that I know Paul Backus had a novel approach to try to make this work, using callbacks in lieu of return values to control safety holes, but I haven't kept up with it in detail (Paul declined to join the OpenD chatroom as of yet). Nevertheless, he has a good record of figuring things out and getting things done, so I wouldn't dismiss anything he's working on without close examination. Robert did not mention Paul's ideas here, so perhaps he is not aware of them.
Timon's tuple work is on the list to explore for OpenD, and Walter continues to show interest (though little action over the last 12 years) in getting it in upstream as well.
I think the idea of making it a kind of syntax sugar for structs is ok, but I do worry about changing the behavior of the built in compiler-tuples, given their prevalence in reflection work and function forwarding. Of course, Timon mentioned all this there and he's generally pretty good about thinking things through, but I might place higher priority on certain concerns than he does. In particular, I'm a bit concerned about the expansion behavior and breaking changes and the trailing comma in argument lists, but we'll see what we can do.
But if need be, we can pick and choose parts. I'd rather have some benefit now than nothing. Not top priority right now, but we'll see what we can do.
Mike showed some basic opengl code with bindbc libraries. The arsd libraries are of course much easier to use, but otherwise this is pretty unremarkable for OpenD; basic opengl code works the same across languages and libraries anyway.
However, one idea that came to me while watching this is maybe we could add a kind of @system("message to user"). See, a lot of OpenGL functions have obviously unsafe (well, really, this code isn't unsafe per se, it is conditionally safe - you must pass the correct combination of runtime parameters to maintain safety, meaning really consistency with the type system. I think we should remember that definition. These functions are unsafe if used improperly, so the real problem is that they're easy to use improperly. But we can abbreviate that to "unsafe" anyway if we remember the deeper meaning), and an easy way to improve upon these is with a small wrapper function. These may be something we can overload based on parameter types.
And that is something you can explain in an error message! So imagine bindings like:
@system("use glVertexAttribPointerBetter(...) instead for safe code") void glVertexAttribPointer(...)
So if you use the function with the problematic interface in a @safe context, the compiler can help point you toward an alternative instead of just stopping at the "You can't do this" error message. With safe by default, this would help people copy/pasting tutorial code learn how to adapt it to the new rules without just slapping @trusted all over it.
I might stick something like this in the OpenD compiler. I like the similar deprecated("message") feature that already exists.
Walter briefly presented an idea for a specific case of implicit conversions that had flaws that were immediately apparent to chat upon initial review. I doubt this will go anywhere; addressing these flaws will probably make you ask if it is worth moving forward at all.
On the other hand, OpenD has implicit conversions in the language that you can try for yourself today with the opImplicitCast method. Our method can surely be abused to do weird things... but as is often true, when you have the power to do great things, that same power can be misused to do not-so-great things too. At least it is opt in though, so we can design things that use the good parts and avoid the bad. Hopefully, of course our experience is still a bit limited right now.
I watched upstream's DConf Online 2024. Some thoughts about how ideas raised there might apply to OpenD.