First day seems very LLM heavy, and sounds quite odd for Phobos 3. I would like to see Phobos 3 be more betterC forward, since I have found D to be nicer than C for WASM, but you can't use most nice things. Having a default RAII vector class for betterC and a hashmap would be super nice too.
Edit: Also would be nice to adopt move and copy semantics even closer to C++ and maybe need less explicit moves, and ideally less mess with calling __xdtor when trying to do RAII
I haven't announced my keynote yet, but it's about various ways of handling errors and their tradeoffs. This has inspired some spirited debate in the D forums! I'm looking forward to engaging with everyone.
What’s the status of the OpenD fork?[0] I see Adam is still active there but I’m not sure if it’s had any impact beyond losing him as an upstream contributor.
Upstream has followed several of opend's innovations: we shipped interpolated expressions on day one of the fork (that was the straw that broke the camel's back) and then, after 7 years of procrastination, upstream also merged it a week later. We shipped extern(Objective-C) support, upstream backported it (and actually fixed enough bugs that I replaced my original impl with their's) a few months later. Upstream has talked about "safe by default" for over nine years. We shipped "safer by default" as a compromise (full safe by default is too much of a breaking change) a few months after forking, then a few months after we shipped it, upstream announced their own "safer by default" switch (which you have to opt into, so they kinda missed the point of "by default" but still, they followed the overall concept). For basically ever, Walter has said null checks in the language were a hard no, we implemented them and then.... guess what, a few months later, my implementation was backported (and again, a few bugs fixed so i appreciate the collaboration when we can get it) and walter decided to allow the merge. Opend shipped druntime on webassembly, looks like something similar coming to upstream. We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.
There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!
Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).
And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.
So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.
> We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.
FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.
I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.
I came in here wondering why a config database is in London. It's quite unfortunate to name your conference after a much more popular, or at least widely used software (try searching dconf in a non personalized search engine)
15 comments
[ 3.2 ms ] story [ 25.5 ms ] threadEdit: Also would be nice to adopt move and copy semantics even closer to C++ and maybe need less explicit moves, and ideally less mess with calling __xdtor when trying to do RAII
You can find such @nogc collections in `dplug:core` or `nulib` packages.
> I would like to see Phobos 3 be more betterC forward.
It is, some part of it is going to be called BaseD and with a more restricted subset, without GC usage.
[0]: https://opendlang.org/
There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!
Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).
And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.
So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.
https://dlang.org/changelog/pending.html#dmd.monitor-field
but maybe this is the first step toward something more useful.
FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.
I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.
https://en.wikipedia.org/wiki/Dconf