The January meeting took place on January 13th at 14:00 UTC. It was a quarterly meeting, which means we invited representatives from companies using D in production. We normally would have scheduled it on the first Friday of the month, but delayed it a bit to allow everyone time to return and/or recover from the holiday period. The meeting lasted around 2.5 hours.

Unfortunately, I overlooked that audio output was disabled on OBS Studio when I recorded the meeting. I can hear myself, but no one else. All the good stuff was said by everyone else. I enlisted the help of some of the other attendees in recalling what we discussed. So what follows is a very light summary of a rather long meeting, cobbled together from the memories of a few different people several days after. I did not get input from everyone who attended the meeting, so I welcome any of them to fill in any additional gaps they may remember.

The following people attended (those with DLF next to their names are either D Language Foundation board members, paid employees, or affiliated volunteers):

• Walter Bright (DLF)
• Iain Buclaw (GDC/DLF)
• Ali Çehreli (DLF/Mercedes Benz R & D North America)
• John Colvin (Symmetry)
• Martin Kinkelin (DLF/LDC)
• Dennis Korpel (DLF)
• Mario Kröplin (Funkwerk)
• Max Haughton (DLF/Symmetry)
• Mathias Lang (DLF/Symmetry)
• Razvan Nitu (DLF)
• Mike Parker (DLF)
• Robert Schadek (DLF/Symmetry)
• Amaury Séchet (Symmetry)
• Robert Toth (Ucora)
• Bastiaan Veelo (SARC)

The summary

Mathias, Martin, Robert T., Iain, Max, and Ali

Robert said he was there to listen this time, but he did contribute throughout. Martin had not had any time since the last meeting to prepare the next LDC release. Iain, Max, Mathias, and Ali simply had nothing to report. I joked with Mathias that I was glad I was recording it (he usually has more than one thing to report, and often brings up something else at the end when I ask if anyone has anything else). Next time, I should knock on wood.

Robert S.

Robert gave an update on the Bugzilla-GitHub migration. He provided some details about its current state and hoped it would be ready to use by the end of the month. I asked if, when the time comes, I should just let it run on a VPN rather than my PC. He said that because of the GitHub API's rate limit, it shouldn't hurt to let it run on my PC. There were then some questions about details, e.g., should the script include only Bugzilla numbers in the migrated issues or link to the original, and I mentioned we should get in touch with Brad Roberts to set the Bugzilla into read-only mode. (This came up again in our February meeting three weeks later.)

Robert had already migrated the tools repository issues, so if anyone wants to see what that looks like they can now. All of the issues from the author dlang-bugzilla-migration were migrated from Bugzilla.

Bastiaan

Bastiaan had encountered an issue on his project at work related to the DMD installer on Windows. The installer has the option to add the compiler's path to the PATH environment variable, but checking it causes it to add the path to the 32-bit compiler even on 64-bit systems. This came to their attention when DMD suddenly started running out of memory when compiling their code base but was only using 4GB. He filed an issue and submitted a fix. Now, the installer with 2.102.0 will set properly the path to the 64-bit compiler on 64-bit systems.

He also brought up a nearly year-old regression with dub related to $PACKAGE_DIR and the sourceLibrary package type. This was initially an annoyance for them but has become a blocker preventing them from upgrading the compiler since 2.100.0.S Jan Jurzita did some work on it last year, but it's still open as I write this summary. I've pinged Mathias and Jan to see if they can get it resolved.

John and Amaury

In the summary of our December meeting, you can read Robert Schadek's report of a Symmetry programmer who moved from D to C# for an internal project, as well as some of Robert's own frustrations. John came to us in this meeting to expand on that and asked Amaury along to provide his perspective.

This was a very long, very heavy discussion. Even if I did have the audio, there's no way I could reasonably cover in detail everything that we discussed. You can get the main thrust of the topic from a forum post John wrote up at the beginning of last December in response to Walter's request for feedback on a Sum Types proposal. Essentially, he's concerned that we keep moving on with new features while there are fundamental problems in the compiler and language that persist. People who are already sold on D and have used it for a long time have learned to live with them, either by working around such issues or ignoring them. That's not an ideal situation, but it's even worse when you're talking about bringing non-D programmers up to speed on D. For them, those little cracks in the foundation add up to a big, gaping hole that turns them off. This is the situation Symmetry and other big D shops face when they have to hire people who have never used D.

Essentially, John and Amaury were making an appeal that we put more value on a solid foundation. Things should "just work".

The conversation about this snaked back and forth, sometimes going off on short tangents, with almost everyone providing input. As I recall, Walter reiterated that he can't do anything with general descriptions of problems; he needs specific issues that he can sit down and fix. John and Amaury both provided some examples. I noted that part of the purpose of my campaign to collect gripes and wishes was to help us identify the kind of fundamental problems they described and get them all gathered in one place and prioritized, then we can figure out how to muster the resources to fix them. We were (and still are) in the midst of a period of organizational development, and I expected we'd be ready to start tackling this sort of thing in April or May. John said that was great, but he hoped we could make progress on some things before then.

That's all the detail I have right now on that discussion. Ultimately, Walter decided to put the Sum Types proposal aside for now and began directing his efforts toward fixing some fundamental issues in Bugzilla. At the end of an email discussion a few weeks later, he and Átila decided that stability and robustness should be our primary focus for the next year.

I'll again take this opportunity to encourage everyone to send me your gripes and wishes at social@dlang.org. What do you consider to be fundamental issues with the language, tools, or ecosystem? Please be as specific as you can.

Mario

Mario said Funkwerk had no pressing issues. However, he wanted to know about any potential plans for multiple alias this. He noted that in the old Wiki-based DIP system, a proposal for the feature had been conditionally approved. He recalled the DIP author had begun an implementation. The status of the DIP had never been updated, so was it still something we were intending to pursue?

Walter said no, we were not going to support multiple alias this. It has the same issues as multiple inheritance and opens the door to the problems that arise from that. This took us into a discussion about alias this in classes, and ultimately a decision that it should be removed from the language.

Mario ended by suggesting that someone should update the wiki page for DIP 66 to indicate that it's rejected.

Razvan submitted a PR deprecating alias this in classes the next day. Amaury initiated a forum discussion a few days later. And I've now updated the status of DIP 66.

Dennis

Dennis asked about the future direction of -betterC. A number of people had raised issues about -betterC disabling DRuntime-dependent features even for CTFE, and while there had been some small fixes, there had yet been no consensus on how to solve the problem in general.

He then listed three possible approaches:

• Explicitly annotate code as CTFE-only with new syntax: pragma(ctfe), if (ctfe) etc. Walter noted that the syntax is an extra ().
• Implicitly make functions using DRuntime features as CTFE-only. This might be surprising and unintuitive
• Generate run-time errors instead of compile-time errors. This makes errors easier to slip by.

Martin suggested a fourth option: phase out -betterC because it's a "pile of hacks". Dennis considered that but thought BetterC users would not be happy when it gets deprecated without a suitable replacement. Walter said that the best approach couldn't be decided in the meeting, and should be discussed in an e-mail/forum post.

As a final question, Dennis asked what the "official" intended use for BetterC was in the first place: just a C migration tool or also something for new D code. I said -betterC shouldn't be used for writing new code. Walter said it can be used for whatever calls for it, be it integrating with C, targeting embedded systems, or any scenario where you don't want to link DRuntime.

Walter subsequently submitted a PR for the compiler to recognize if(__ctfe) blocks and a companion PR to disable the generation of TypeInfo in if(__ctfe) blocks.

Razvan

Razvan asked what everyone thought about a specific Bugzilla issue. Given an aggregate type F, the compiler allowed taking the address of a member function F.foo without an instance of F, returning a function pointer rather than a delegate.

Razvan had submitted a PR in December. His fix was to simply type what is returned as being void*. This would keep the current behavior, but it would be @system require a cast to the desired type in order to use it. However, there were folks that didn't want to lose the type information and proposed instead to have some extra typing on the result, such as void delegate(S*).

It seems the end result was a recommendation for the latter, as that's what Razvan amended the PR to implement. However, that apparently led to a new issue, and the PR is yet to be resolved.

Razvan also let us know that the GSoC application period was opening on January 23rd, and asked us to contact him if we had any project ideas or were willing to be a mentor.

Walter

Walter is always the last to take a turn in our meetings. On this occasion, he felt like the meeting had gone on long enough. During the discussion about fundamental problems, he mentioned his frustrations with how build.d is invoked by the compiler under test when running the test suite. He had nothing else to report. (This issue with build.d was the topic he brought up during his turn at our February meeting).

The next meeting

Our next meeting took place on February 3rd at 15:00 UTC. It was a monthly meeting.

If your company is using D in production and you'd like to send a representative to our quarterly meetings, please let me know! We'll do what we can to help solve any issues you may have with D, but we're also interested in hearing your perspective on the topics we discuss. Our next quarterly meeting should take place on April 7th.

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

>

The January meeting took place on January 13th at 14:00 UTC. It was a quarterly meeting, which means we invited representatives from companies using D in production. We normally would have scheduled it on the first Friday of the month, but delayed it a bit to allow everyone time to return and/or recover from the holiday period. The meeting lasted around 2.5 hours.

[...]

betterC is much more important for some user, please don't phase out -betterC.

with betterC you can target into new platform without much work, and easy to deal with dynamic library, generate much fast and smaller binary.

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

>

...

Dennis

Dennis asked about the future direction of -betterC...

... He then listed three possible approaches:

• Explicitly annotate code as CTFE-only with new syntax: pragma(ctfe), if (ctfe) etc. Walter noted that the syntax is an extra ().
• Implicitly make functions using DRuntime features as CTFE-only. This might be surprising and unintuitive
• Generate run-time errors instead of compile-time errors. This makes errors easier to slip by.

Martin suggested a fourth option: phase out -betterC because it's a "pile of hacks"...

As a final question, Dennis asked what the "official" intended use for BetterC was in the first place: just a C migration tool or also something for new D code. I said -betterC shouldn't be used for writing new code. Walter said it can be used for whatever calls for it, be it integrating with C, targeting embedded systems, or any scenario where you don't want to link DRuntime.
...

In the recent post by Mike Parker, betterC is used as a great alternative to C for writing bare-metal RISC-V application:

https://forum.dlang.org/post/eemwycjmfqvedgggnvnr@forum.dlang.org

I use -betterC because i can focus on the language and build upon it, i don't have to deal with the slowness of phobos and more importantly, i don't have to wait for phobos or druntime to be ported to WASM in order to be able to target to WASM, i target WASM today

It also makes me confident that none of my game code will accidentally call the GC, as i banned the use of the GC for this particular project (game)

I can focus on what i love about C with the greatness of D (the language)

My project fully recompile (clean build, game+engine) in just 1.2s, thanks Walter!

The only complain i have about betterC, and D in general are the error messages, sometimes just having new lines with proper spacing makes errors easier to read, i made a comment in one PR(related to improving betterC error message) that it was helpful and very much welcome, so looks like things are going to improve

>

Walter decided to put the Sum Types proposal aside for now

That's super sad to hear.. i was eagerly hoping tagged union would come sooner rather than later.. it's one feature that enables writing useful with less noise

I want to replace that kind of ugly code that i have, notice how easy it is to have bugs if you are not careful what field you use, not safe!: (no, template is not the solution)

enum EventType: ubyte
{
    QUIT,

    GFX_RESIZE,

    INPUT_KEY_DOWN,
    INPUT_KEY_UP,
    INPUT_KEY_TYPED,
    INPUT_TOUCH_DOWN,
    INPUT_TOUCH_UP,
    INPUT_TOUCH_DRAGGED,
    INPUT_MOUSE_MOVED,
    INPUT_SCROLLED,
}

struct Event
{
    long time;
    bool consumed;

    EventType type;
    union
    {
        // GFX
        Resize resize;

        // INPUT
        KeyDown key_down;
        KeyUp key_up;
        KeyTyped key_typed;
        TouchDown touch_down;
        TouchUp touch_up;
        TouchDragged touch_dragged;
        TouchMoved touch_moved;
        Scrolled scrolled;
    }
}


(..)


        // update key state
        foreach(Event* e; engine.queue)
        {
            if (e.consumed) continue;

            switch (e.type) with (EventType)
            {
                case INPUT_KEY_DOWN:
                    switch(e.key_down.key)
                    {
                        (..)
                    }
                break;
                case INPUT_KEY_UP:
                switch(e.key_up.key)
                {
                        (..)
                }
                break;

                case INPUT_TOUCH_DOWN:
                    if (e.touch_down.button == 1)
                        (..)
                break;
                case INPUT_TOUCH_UP:
                    if (e.touch_up.button == 1)
                        (..)
                break;

                default:break;
            }
        }

I think expecting users to ask for new features shouldn't be seen as something bad

It's great to have people discuss language improvement, it gives the ability to talk about and remind people about existing features, and potentially their issues

And what a better opportunity than to remind ones who think bugs in weird and cryptic corner cases, is what turn off people

What turn me off from D is that kind of issues: https://github.com/dlang/dub/issues/2600

When you start to import things from the std and it makes your compile time go from 5seconds (already an eternity) to 10 seconds, and people think "it's not a problem"

tagged union would help reduce the code complexity, template usage and bugs by a significant amount of time, as well as improving error messages https://forum.dlang.org/thread/zsxipgibubqgnwwwxhqx@forum.dlang.org

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

>

Razvan submitted a PR deprecating alias this in classes the next day. Amaury initiated a forum discussion a few days later.

Is there a replacement? If not, why is this even being discussed? I'm all for breaking changes if there's a benefit and an easy path to maintain the existing functionality. This fails on both counts. If you want to enforce that it's not used, add a flag, but don't take it away just for the sake of taking it away.

>

Martin suggested a fourth option: phase out -betterC because it's a "pile of hacks". Dennis considered that but thought BetterC users would not be happy when it gets deprecated without a suitable replacement.

If you don't like BetterC, don't use BetterC. It already requires a flag.

More generally, deprecation decisions like this shouldn't be made by a small group of people that write a tiny percentage of the D code running in the real world. That same process gave us a safe by default proposal that would have made it impossible to interoperate with C code.