Permalink
Reply
Monthly Meeting
The D Language Foundation's monthly meeting for February 2022 took place on February 4 and lasted around 1.5 hours. The following foundation members, contractors, and contributors attended:
Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker
Me
I opened the meeting with a question for Walter. After a recent forum discussion, someone had submitted a DIP that would change the runtime behavior of the default toString implementation in the Exception class such that it generates stack trace output only when an environment variable is set. Should this be a DIP or an enhancement request in Bugzilla? We had a brief discussion.
Vladimir pointed out that stack trace output is only useful when debug symbols are enabled.
Ali suggested that perhaps it could be configurable for Exception, but Error should always print. Átila and Mathias noted that anyone who wants this can just catch all Exceptions in main. This doesn't handle static constructors, but they both said that static constructors that aren't nothrow are probably wrong anyway.
Walter said a DIP isn't needed---it's fine to post it in Bugzilla as an enhancement request.
Later, at the end of the meeting, Martin said he had looked into the DRuntime source. The stack trace handler is configurable by the user, so there may be no need for an enhancement request. It should be sufficient for the user to set the trace handler to a function that returns null.
Martin
Martin said he was eager to see news about the 2.099 release. He felt it was the right time for the stable branch to be updated as some important breaking changes had recently made it into the compiler. This brought about a discussion about the number of the next version after 2.099: should it be 2.0100 or 2.100? The latter would match what we did with the pre-1.0 releases, which went up to 0.178. We moved on quickly from this discussion without any definitive statement, but my impression is that we're leaning toward 2.100.
The beta for 2.099 was announced on February 17.
Martin later reported that he has worked on template emission in unit test mode. When compiling with -unittest, it used to behave similarly to -allinst, but now emissions have been significantly reduced. The best benchmark of ~20 projects from Átila showed a 36% reduction in memory usage and compile time. There are still some things that can be culled even more.
Iain
Iain said the most productive thing he'd done over the previous month was removing ~5,000 LOC from DRuntime in the form of redundant bindings. Other than that, he agreed with Martin about the stable branch.
Vladimir
Vladimir opened with a progress report. Back in December, we discussed migrating our Bugzilla issues to Github. An alternative solution is to upgrade to Bugzilla Harmony, a project Vladimir had been contributing to for some time. After that meeting, we agreed that Robert Schadek would move forward with implementing his migration script, while Vladimir would get the new Bugzilla instance set up so we can test it out in the interim.
Unfortunately, he reported that he has encountered a blocker. He needs the configuration files for our active Bugzilla instance, but the maintainer has so far been unresponsive. For now, he will continue working on Bugzilla and will keep trying to get the configuration files. (On a side note, this is one reason why we plan to get all of the services in our ecosystem under one roof with access for multiple admins. We're thankful for all of the work the volunteers in our community have put into maintaining services for us, but we've grown well beyond the point where we can live with having a single point of failure for every service in the ecosystem.)
Ali
Ali reported that he finished his Programming in D edits, saying that the physical book is updated as well.
Razvan
Razvan gave us a report on the status of [the leaderboard for the Bugzilla rewards](https://bot.dlang.io/contributor_stats. He added asterisks next to the names of those ineligible to receive rewards, and he also added another page: https://bot.dlang.io/contributor_stats shows overall stats, and https://bot.dlang.io/contributor_stats_cycle shows the stats for the current cycle. He told us he was thinking of theming the page based on the DConf logo and colors from 2016/17 in Berlin, and he has since done so.
He also brought up the vision document.
In the discussion thread of our September 2021 meeting summary, I said the following in response to a question about the vision document:
>...in the process of revising it, I realized it needs a complete rewrite. The document we ended up with isn't what we said we wanted.
The rewrite will be a high priority for me once I wrap up the DConf Online Q & A videos and get the DIP queue moving again
At the time of the meeting, I was still working on the last DConf Online video (the AUA), so I wasn't quite ready to turn my attention to it yet. I had intended at some point to propose a special meeting to discuss it, but since Razvan brought it up I suggested we hold that meeting on February 18. Everyone agreed. We did have the meeting, and you'll find a brief summary of it below.
Átila
Átila had nothing to report.
Mathias
Mathias brought up a PR he had submitted to dmc a year ago. It adds CI. He asked if Walter could provide feedback on it. Walter asked him to send him an email with the link, and Mathias said he would do so as soon as he rebased the PR.
While putting together this summary, I followed up with Mathias. He has now rebased the PR, and I've sent Walter the link.
Walter
ImportC
Walter told us how he thinks ImportC is going to be a big deal for D. He wants to get us "over the hump" with getting it working properly. He thinks his C extension to allow importing D files in C is working out far better than he expected, and he's considering proposing it to the C committee. The biggest difficulty with ImportC is compiler extensions that we either have to implement or give up on.
Walter asked Iain and Martin if they were going to implement ImportC in GDC and LDC.
Iain explained that it will be used when importing a C header into a D program, but any C files passed on the command line will go through the GCC driver and be handed off to the C compiler. Walter asked if GDC could get a command-line flag to bypass the driver and pass C files to ImportC instead of GCC, and Iain said that's not possible. He and Walter brainstormed ways to do it, but Iain said GDC has no control over the main function. He also noted that GCC is already a good C compiler, so he doesn't see a reason to bypass it.
Martin said you can currently import C headers and compile C source with ImportC in LDC, but he hasn't yet implemented the two new AST nodes that Walter implemented for ImportC in DMD's backend (initializer lists and bitfields). He hopes to handle those in the glue layer and output errors saying LDC currently has limited ImportC support. Implementing bitfields is going to take a bit of work.
Walter said he now thinks having the C initializers flowing through to the backend in a new AST node was a mistake. He plans to change the implementation so that the frontend semantic routines translate them into D initializers.
Bitfields
Walter then brought up bitfields in D. He had expected it was going to be an obvious, uncontroversial feature, and was surprised by the resistance to it.
The number one objection he's seen is that it would break the reflection API. He noted that bitfields will work with the reflection API without breaking anything (callers will get a field that is a union of the bitfields, so its address can be taken, and it will have a name derived from "bitfields"). We can add a traits feature that specifically fetches a bitfield.
Martin said he was satisfied with that solution, but wondered what would happen when taking the address of a bitfield. Walter said that would fail to compile. Martin feels this hurts the elegance of the language just for the sake of a rare case for which there has been no big demand and for which we already have a library solution ("not great", but it works). This went into a long discussion about opportunities for compression of data structures (particularly in DMD), whether or not that's beneficial for DMD, compatibility with C, library vs. language solutions, experience reports (Mathias described how his company handled bitfields in bindings not using the library solution), improving the library solution so that it's more elegant, the bitfield implementation in ImportC, C compiler bitfield layouts, and quite a bit more.
128-bit integers
Finally, Walter said he has looked at implementing 128-bit integers (cent and ucent), but implementing them in DMD would be a nightmare. After more thought, he has decided it's probably better to implement them as a library type. He mentioned how complex numbers were ripped out of the compiler and implemented as a library feature. The work that has already been done on cent/ucent will not be wasted, as it can still be built on to implement the library type.
Max
Max on a whim began implementing the string interpolation of the DIP under development (not yet submitted) by Andrei and John. He asked if it's okay to go ahead and finish it up and put it behind a preview switch. Walter hadn't seen the DIP yet but noted that he was strongly opposed to any complicated string interpolation feature. The implementation of string interpolation should be easy to explain to anyone. Anything that is complicated to explain just isn't going to work. He will need to review the DIP before deciding on allowing a preview switch.
I suggested finishing the named arguments implementation should be a higher priority right now, and Walter agreed. Walter stressed that named arguments need to be interchangeable with struct initializers. We'll have to keep struct initializers around for backward compatibility, but he wants named arguments to replace them generally.
Vision Meeting
The vision meeting took place on February 18 at 15:00 UTC. The following members attended:
Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker
Robert Schadek
One of the things we were missing from our initial conversations about the vision document last year was an overarching Vision Statement. This is the elevator pitch that describes where D is going. It isn't down at the level of specific details, but far up above. It's a broad, general statement about our long-term goals for the language. This will sit at the top of the vision document. While the rest of the document will change as priorities shift and tasks are completed, the vision statement should remain fairly constant. The more specific details in the rest of the document should all be there because they are sending us on the path described by the vision statement.
I asked everyone present to brainstorm. What do you want for D? Where are we going with it? If there were an end goal, what would it be? No idea, no matter how broad or how specific, was off-limits. The more information I have to draw from, the better.
Each person has their own ideas about the specifics of where we need to go, but I was confident we could find a consensus at a higher level. I'm not going to copy here every item on the list or summarize the entire discussion. The meeting lasted over an hour and we covered quite a bit of ground. However, many of the items fall under broader categories related to the usability of the language and the quality of the overall user experience (i.e., the ecosystem, Phobos).
I haven't gotten to it yet, but the next step is on me. I'll draft three or four different vision statements, then we'll hone in on something that makes us happy. Once we have that, I can start assembling the details for the rest of the document. My current plan is to lay it out in three sections:
Current Focus: This describes where Walter and Átila are currently directing their attention and what their end goals are. It also serves as a guide for volunteer contributors looking to fix bugs or make other contributions, e.g., bug categories related to Walter and Átila's work, suggestions for how to test related language features, ideas for projects that can help reach their end goals, etc.
Future Focus: This describes possible directions toward which Walter and Átila would like to turn their attention in the future, also with suggestions for volunteer contributors. Those who feel their skills are better applied toward one of these areas than those of the current focus can do so knowing that their work will move us toward the desired goal.
Wishlist: This is a grab bag of ideas ranging from small tasks to large projects. Some of them will be things that would be nice to have, but that Walter and Átila will never have time to work on. Some may be important tasks that don't fit into the broader focus categories above, things that either Walter or Átila will have to do at some point if no one else does. Some of these may be set up as paid contract work.
I can't say with any certainty how long it will take us to get all of this together. I know many in the community are eager to see it. Speaking for myself, it's not my highest priority at the moment. I'm sure that's true for everyone else whose input will be required to get to the final version. But I am making sure it gets done, step-by-step, section-by-section. My loose goal is to have it completed before DConf.
The Next Monthly Meeting
I'm quite late putting this summary out, so it's already almost time for our next meeting. We're scheduled to hold it on March 4 at 15:00 UTC. I plan to put forward a proposal about the next step in getting our services under one roof with multiple admins. If you have an idea or issue you'd like to bring to us at this or a future meeting, please contact me at social@dlang.org and I'll see about getting it on the agenda.
