Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat wrote: On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: 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. What would be really cool and end-game would be if the gap between druntime and custom runtime such as HipremeEngine would be smoothed out and only one druntime needs to exist. I think this has been the direction for years: ProtoObject, Object.factory, etc. In the experience I got from dealing with the D runtime, this is what I feel like it needs: Compiler could support a flag which is basically saying: User must provide hook functions such as malloc/free, exit(or assert) (those are the most basic ones), for the runtime to work. So, instead of being dropped on a static assertion with plenty of types not found, you get into a runtime error from the features actually being used. That way, no one will ever need to create a custom runtime that does nothing only for the sake of it being compiled. This is all possible to implement too by using weak compiler attribute. The custom runtime I done is roughly 99% of what the current runtime is, the only difference being those allocators and not supporting throw because I don't know how to implement stack rewinding. While that is not done I'll keep maintaining my own for accessing those unimplemented systems.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat wrote: I think this has been the direction for years: ProtoObject, Object.factory, etc. These things don't really help with it unfortunately, but yes, this is the best goal.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: 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. What would be really cool and end-game would be if the gap between druntime and custom runtime such as HipremeEngine would be smoothed out and only one druntime needs to exist. I think this has been the direction for years: ProtoObject, Object.factory, etc.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 23:00:41 UTC, Mike Parker wrote: On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: betterC is much more important for some user, please don't phase out `-betterC`. BetterC isn’t going anywhere. Too many people use it. Using word "Too" is scary enough for me here :D
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: betterC is much more important for some user, please don't phase out `-betterC`. BetterC isn’t going anywhere. Too many people use it.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. That is not my understanding from the linked thread. For instance, someone said it can be used as a substitute for multiple inheritance. It seems that anyone using it that way would be losing working code for no reason due to this deprecation.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. Generally speaking, I agree, but it does add a little bit of mental overhead for a user if they want to change from struct to class. Hopefully the error message of a class alias this points users in the direction of inheriting instead.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:25:29 UTC, Adam D Ruppe wrote: On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote: In the recent post by Mike Parker, betterC is used as a great alternative to C for writing bare-metal RISC-V application: Real D can do this too. Oh, that's a bit new information to me. But yes, I do not use betterC and I am not dlang-savvy, so happy to hear standard dlang can do as well.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:24:38 UTC, Adam D Ruppe wrote: On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: with `betterC` you can target into new platform without much work, and easy to deal with dynamic library, generate much fast and smaller binary. you can do this without betterC too. often easier. And it could be even easier with a little bit of work that benefits everybody. The custom runtime route is a mistake to expect from users, why should i manage all of this, it should just work, well you are forced because of X, Y, Z are not yet ported! so you cherry pick on a code basis, rather than on a feature basis You'll also have to keep track of the compiler developments in case runtime hooks get changed, also if you are not careful about your implementation you have silent bugs (i had one with switch errors that was hard to track down, i had to copy/paste code from your repo) With C/C++ and even Rust/Zig/Go(tinygo), you don't have that kind of problems The bare is set by other languages already, -betterC is helping staying on buisness for that kind of purpose
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) 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.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote: In the recent post by Mike Parker, betterC is used as a great alternative to C for writing bare-metal RISC-V application: Real D can do this too. betterC needs to die, it is just arbitrary special cases that add tech debt to the compiler and distract from D's real capabilities.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: with `betterC` you can target into new platform without much work, and easy to deal with dynamic library, generate much fast and smaller binary. you can do this without betterC too. often easier. And it could be even easier with a little bit of work that benefits everybody.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
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)
```D
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/zsxipgibubqgnwwwx...@forum.dlang.org
Re: D Language Foundation January 2023 Quarterly Meeting Summary
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/eemwycjmfqvedgggn...@forum.dlang.org
Re: D Language Foundation January 2023 Quarterly Meeting Summary
I just want to make this point about -betterC.
As a switch it should just be switching other things off. As a result
its just a marketing name of D without the language extensions that
depend on druntime.
It isn't that way in practice, but it should be.
However I think there is a pathway forward here.
My number 2 priority for me this year is to see compiler hooks resolved.
They should ALL look like this (more or less):
```d
void hook(T)(T thing) {
version(Feature) {
} else
static assert(0, "feature not had, can't do Y");
}
```
Lowering should be the last step but only for functions that need to be
codegen'd.
This allows significant simplification in the compiler, and allows for
features to work at CT that won't go into the binary.
There is a lot to this strategy that I am not saying here as it isn't
relevant to -betterC. There is some very real possibility here to making
our lives better I think.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
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.
D Language Foundation January 2023 Quarterly Meeting Summary
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`](https://github.com/dlang/tools/issues?q=is%3Aissue+is%3Aopen+author%3Adlang-bugzilla-migration+sort%3Aupdated-desc) 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](https://issues.dlang.org/show_bug.cgi?id=23623) and [submitted a fix](https://github.com/dlang/installer/pull/555). 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](https://github.com/dlang/installer/pull/555) 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](https://forum.dlang.org/post/xamclovgxzzrjznte...@forum.dlang.org) 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
