• Mike Parker (482/482) Jan 20 2023 The December meeting took place on the 3rd of the month at 15:00
• Richard (Rikki) Andrew Cattermole (14/14) Jan 20 2023 A very big problem we have right now is that we are on pretty shaky
• Sergey (4/15) Jan 21 2023 Thank you Mike and all D foundation. It was very pleasant read.
• Mike Shah (3/19) Jan 21 2023 Agreed 100%, these summaries and the transparency into the
• Adam D Ruppe (38/52) Jan 21 2023 We should revisit this decision. I don't think it ever made
• ryuukk_ (30/67) Jan 22 2023 I agree with that 100%, perhaps the feature should be built in
• H. S. Teoh (74/103) Jan 23 2023 This may seem like a small item, but it's a landmark!! The first PR for
• Adam D Ruppe (12/18) Jan 23 2023 http://webassembly.arsdnet.net/
• H. S. Teoh (17/39) Jan 23 2023 Ahahahaha... just like Adam to have already dunnit while I'm still
• Hipreme (56/99) Jan 23 2023 I was going to wait a little bit on that announcement. But yes,
• =?UTF-8?Q?Ali_=c3=87ehreli?= (19/23) Jan 23 2023 Yes! :)
• Siarhei Siamashka (13/18) Jan 23 2023 Do you mean second to last? The safety offered by D language
• Walter Bright (3/4) Jan 24 2023 It does (and always has) resolved the #1 memory safety problem - buffer ...
• Johan (11/18) Jan 28 2023 Is there a document describing cases where removal of `@property`
• Paul Backus (14/22) Jan 28 2023 Given that the only thing `@property` actually does is change the
• Walter Bright (12/18) Jan 28 2023 It's been a while, but I think the only difference is if you're taking t...

Mike Parker <aldacron gmail.com> writes:

The December meeting took place on the 3rd of the month at 15:00 
UTC. The following people were present:

* Andrei Alexandrescu
* Walter Bright
* Ali Çehreli
* Dennis Korpel
* Mathias Lang
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek

The meeting lasted around an hour and a half.




Dennis opened by reporting that he had begun working on a DIP to 
use ` default` as a means of resetting attributes. He had a 
question about what it should affect: should it reset all 
attributes (including visibility attributes like `private`), or 
only function attributes? The unanimous consensus was that it 
should only affect function attributes. He has since [submitted 
the DIP for Draft Review](https://github.com/dlang/DIPs/pull/236).


__ property__

In his ongoing effort to resolve old Bugzilla issues, Razvan had 
encountered a number of old issues regarding ` property`. Walter 
and Andrei had said in the past that we shouldn't support the 
feature anymore, and it's often recommended that people not use 
it. But people do still use it. So what are we going to do about 
it? Should we attempt to fix these old issues? Should we 
deprecate ` property`?

Walter suggested one possible approach is just to leave it as is. 
Those who see a benefit in using it can continue to do so, and 
those who don't can avoid it. He hadn't looked into the issues 
surrounding ` property` in a long time and asked if this was a 
viable approach. As far as he understood, the only time 
` property` has an effect is when you take the address of a 
function it annotates. Razvan said ` property` sometimes 
interacts with other features in unexpected ways and the spec 
says nothing about what it's supposed to do. Maybe we could just 
add something to the spec saying it shouldn't be used.

Andrei said that's not what a spec is supposed to do. A spec 
tells you what happens when you, e.g., move your hand like this. 
A spec doesn't give you advice. If we're keeping it, we should 
spec it out even if we then never touch it again. Guides will say 
whether or not to use it. But we can't just leave it hanging 
unspecified.

Ali noted that he didn't include it in his book other than to say 
using it is discouraged.

Razvan asked how he should handle these ` property` issues in 
Bugzilla. Find someone to fix them or just document the behavior? 
Walter said the latter. He also suggested adding a recommendation 
to avoid ` property` in the best practices section of the 
documentation.

Robert spoke up then to suggest deprecating ` property` and 
releasing a tool that removes it from a code base. Then we should 
apply that tool to create pull requests for all dub packages 
using ` property`, and then in a future release, we kill it. 
Anyone affected by the removal can then run the tool on their own 
code. He added that we should do this with any feature we decide 
to remove. This is the modern way of software development: you 
don't just break someone's code, you break their code and give 
them a tool to fix it.

Átila said that would work fine here except in cases where 
someone is taking the address of an ` property` function. We 
aren't going to be able to make a tool for that. Robert said 
that's true but do it anyway. The tool should tell them, "This 
doesn't work for this case. Sorry." He said that if we test the 
tool with all the D code we can find on GitHub, he'd bet beers at 
DConf that we'd find no more than ten instances of code that 
would break.

After more discussion in a similar vein, Razvan said what it 
comes down to is that this is a broken feature and we don't know 
how to fix it. We need to just deprecate it. We shouldn't be 
keeping broken features around if we aren't going to fix them. 
Robert agreed. A tool to remove it from code will handle most 
cases, and for those people whom it doesn't help we'll have to 
help them migrate.

There was then some discussion about whether or not ` property` 
is fixable. Dennis brought up the case of when the property is a 
callable (and linked the [docs for Adam Ruppe's `arsd.jsvar` 
module](http://arsd-official.dpldocs.info/arsd.jsvar.html) as an 
example of the problem manifesting; see Adam's comment in the 
example code and his notes near the bottom of the page). If we 
want to support this kind of type that can store callables, then 
we need some kind of fix. Walter said that's an ambiguity for 
which no one had been able to settle on a solution.

Andrei said one intent of ` property` is to be a replacement for 
a data member. That's a good goal. Any improvement of ` property` 
should serve that purpose. If there's an ambiguity, it should go 
in favor of that. Átila thought that made sense. If there's an 
ambiguity, then just pretend it's a field. If there's only one 
set of parentheses, you call the callable. If there are no 
parentheses, you call the callable.

Robert countered by saying we're trying to make D simpler, and 
` property` makes it more complicated for very little benefit. 
Properties are functions and then attributes like ` safe` play 
into it. Simpler is better.

Walter said that when you have special cases for a feature like 
this, you have to ask, is it carrying its water? He thinks 
` property` isn't. Átila argued that there is something to be 
said for what it enables when it comes to refactoring. It 
increases the plasticity of the code. Robert said that's fine for 
existing users, but it doesn't help new users. Kill it and make a 
tool.

To wrap this up, Walter said that on the list of problems that we 
have to deal with, ` property` is down towards the bottom. Unless 
this is something affecting a significant number of our users, 
it's not something we should spend time on. He's happy with just 
deprecating or ignoring it.

Razvan noted that simplifying the language is part of our vision, 
and this seems like a good candidate. Walter agreed. Dennis 
suggested going through DRuntime and Phobos to look at all 
instances of ` property` and seeing if they could be removed. 
Walter agreed.

__CTFE writeln__

Razvan next brought up [a PR to implement a `__ctfeWriteln` 
built-in](https://github.com/dlang/dmd/pull/12412). It was 
currently stalled and needed Walter's approval. Walter asked 
Razvan to email him about it. He subsequently approved it.

__Reducing Phobos template bloat with traits__

Razvan next noted that compile time was a recurring topic these 
days and [cited a recent 
thread](https://forum.dlang.org/post/ahhgsnvoimnpsxabjasv forum.dlang.org).
Template bloat in Phobos is often cited as one of the culprits. He brought up
the `std.traits.fullyQualifiedName` template as a specific example. Every
instantiation of it results in an additional 10 to 15 template instances. In
this case, changing it to a `__traits` would be a big improvement. On the other
hand, we've been reluctant to add new traits. What should the policy be when
there is an obvious opportunity to reduce Phobos template bloat with a new
trait?

Walter said that `__traits` is meant to be ugly. It's meant to be 
a sort of catchall for random stuff. Reducing template bloat for 
a commonly used template is a very worthwhile reason to add a 
trait.

Walter then noted that `isPointer` had come up in the same 
thread. He looked at its implementation and found it was trivial. 
Trivial stuff generally shouldn't go into Phobos. The library 
shouldn't be a mile wide and an inch deep of functions. He went 
through Phobos and removed all the uses of `isPointer`, though he 
left the template there for backward compatibility. He also did 
that with `implicitlyConvertible`. In both cases, he replaced the 
usage of the templates with the equivalent `is` expression. Átila 
noted that the templates are still necessary if you're static 
mapping or filtering, and Walter said that's why he didn't remove 
them.

Walter said that's one approach to getting rid of template bloat: 
flattening out the number of instantiations. There are a number 
of cases where Phobos templates forward to another template when 
they really didn't need to. Andrei said that's mostly historical, 
in some cases it was done to avoid bugs, and he agreed that 
flattening out instantiations is a good thing to do.

Andrei said that we should discourage bad practice as a matter of 
course, but the notion that we have template bloat because of 
abstraction is a bit of a problem. Consider that `__traits` is 
ugly because it was intended to discourage direct use and for use 
instead inside an abstraction layer. Now we're kind of changing 
the charter and saying you should use `__traits` because if you 
wrap it in a template it's going to produce code bloat. What's 
the deal?

Walter said the problem isn't wrapping `__traits` in templates. 
Templates should use `__traits`, not a whole bunch of wrapper 
templates. The problem is that we have to ensure that we aren't 
creating a nest of template instantiations because too many 
nested templates slow compilation. We want Phobos to serve as an 
example of how to do things, but it also needs to be performant. 
That means making some concessions to performance.

Robert said that doesn't solve his problem with compile times. He 
has a project that doesn't use much of Phobos, but compile times 
still suffer. The compiler is slow. Making Phobos a tiny bit 
faster doesn't change that. Changing the template implementations 
is like saying you can't use our screwdriver with big screws. 
Doing that gets you maybe from Level 30 to Level 29, but it 
doesn't solve the problem.

Walter said Robert was right about the compiler. But that's a big 
and difficult problem to solve. What we can do right now is 
reduce the nesting of templates.

Razvan sees these as two completely different problems. One is 
that the compiler is slow. The other is that Phobos has template 
implementations that are wasteful. We need to solve both. And 
even Walter's changes are only a minor dent in the Phobos 
bottleneck. He had previously dug into `hasUDA` and it was scary 
how many recursive expansions he found. And we don't provide the 
tools for the user to understand where the bottlenecks in their 
template usage are at.

Walter brought up the `-vtemplates` compiler switch for reporting 
template statistics which was added at Weka's request. Razvan 
said there had been some complaints raised that it doesn't 
provide enough information. Átila said what we're really missing 
here is compile-time profiling.

Andrei suggested a longer-term project we can consider. Most of 
the time when people modify their code, they aren't changing the 
template instantiation but the code around it. That goes to the 
idea of caching or pre-compiling the template so that further 
compilations don't take so long and only compiling the template 
when the instantiation has changed. This idea has come up a 
number of times over the years, and it may be time to bring it to 
the front burner. Átila brought up C++ 11's extern templates. 
Andrei said that's not what he meant. He's talking about a little 
database that the compiler creates to save the instantiations. 
It's not extremely difficult, but it's a big project. And he 
suspects it will transform the problem into a non-issue. He 
thinks it would be an excellent project.

(This discussion ended after that, with Razvan saying, "Sounds 
good to me". My impression is that we're going to explore the 
caching idea at some point.)


Mathias wanted to let us know about two things he was working on 
regarding dub.

The first involved dub's settings file, `settings.json`. As he 
put it, have you ever seen a program that asked you to write its 
settings using JSON? There had been [some favorable responses to 
the idea of moving to 
YAML](https://github.com/dlang/dub/issues/1832) from some core 
contributors a few years back. It just needed someone to do it. 
He asked if we were okay with the move. Átila said we probably 
shouldn't keep JSON, but wondered if YAML was the best choice. 
What about TOML? This sparked a minor bikeshedding discussion, 
but there was no major opposition to Mathias's plan. ([He has 
since opened a draft PR](https://github.com/dlang/dub/pull/2546). 
Sönke Ludwig wants to see a broader discussion of this before 
finalizing it, so I expect Mathias will ask for community 
feedback at some point.)

The second issue was dub's build cache. When you build something 
with dub, you end up with a large number of build artifacts in 
the working directory of the package being built. It's not just a 
few MBs, but hundreds. Different flags and compiler versions 
create separate directories, so it can quickly go into GBs. He 
had [an open pull request to change that 
behavior](https://github.com/dlang/dub/pull/2542) so that the 
artifacts go into a .dub/cache directory rather than the CWD (the 
PR has since been merged). That's the first step, getting output 
into a single location. The next step was to make it configurable 
for the users.

I asked Mathias who is the best POC (point of contact) for dub. 
Was it still Sönke? Was it Mathias or Jan Jurzitza? He said that 
would be him (Mathias). Several months ago he had gotten annoyed 
with the state of dub and had done a bunch of work on it. Sönke 
is around from time to time, but he has little time for it these 
days. Mathias usually leaves his PRs open for a while so someone 
can review them, and sends them to Jan, but he manages most of 
the PRs himself.


__D frustrations__

Robert let us know about a programmer in Symmetry who had a 
project in D that was going to transition from a toy to 

production version. There were a number of little annoyances and 
pain points with D that led to that decision. Robert said that he 
had been with D so long that those little things don't hurt him 
anymore, but on reflection, they do hurt.

He noted that with the 2.101 release, Jan Jurzita's LSP (Language 
Server Protocol) implementation started crashing. Compile times 
keep getting slower. Why doesn't an LSP implementation come with 
DMD? Why don't we have a compiler daemon? Why aren't his build 
times sub one second? Why are we talking about adding ` live`, 
tagged enums, and all that stuff? He just wants a simple language 
that works out of the box with LSP that isn't too crazy. We're 
talking about how to fix memory safety, but it's such a 
complicated issue. We're trying to make the language simpler, but 
the combination of features being added is exploding in our faces.

When Robert uses D, he feels there's a simple, straightforward 
compiled language in there that knows what it is. Sometimes he 
feels he's the only one that sees that and that other people want 
more elaborate features. Átila agreed and mentioned his DConf '22 
talk, saying we need to fix what's already there before we 
consider more features.

Robert feels like the way we write and build software with D is 
15 years behind the curve. Compiling isn't really a batch job 
anymore. The compiler should be a daemon with built-in LSP that 
compiles files when they change. Andrei's earlier comments on 
caching templates would benefit from this. He knows it's a 
gigantic change, and would require a complete rewrite, but it's 
easier to start now than two years down the line. He knows he's 
not capable of doing it, and he doesn't have the time even if he 
were, but he thinks it needs to be done.

Though this frustrates him sometimes, he enjoys writing D every 
day and wants to do it for the rest of his life.

Walter asked if Robert could get the Symmetry programmer who 

give up on D. Robert said he would try. Walter said that the 
horse has left the barn with this programmer, but those issues 
are probably affecting other people. He noted the forum posts 
about the guy who dropped D for Jai. Walter had the impression 
that the person had filed multiple bugs, but it turned out he had 
filed three. Walter had been able to fix two of them. He then 
sent an email asking if there were other bugs to fix, and the 
person was very nice but couldn't come up with other bugs to fix. 
However, those bugs he'd fixed were important ones, and Walter 
hadn't been aware of them before. They were ABI problems with the 
Microsoft C compiler. The MS documentation was wrong about the 
ABI, so the code generation was wrong.

This was followed by a discussion about how to solve the small 
annoyances and issues people have that they find so frustrating. 
Walter said the big problems aren't so easy, but the small ones 
should be. He said we absolutely need to fix them, but we need to 
know what they are. He expressed frustration that he often has a 
hard time getting actionable items from people when it comes to 
the small stuff. That's why he's always asking for Bugzilla 
issues.

Robert understood, and he had seen the same. He reiterated that 
his Number One actionable item was adding an LSP implementation 
to the compiler. He then explained the benefits this could 
provide if the compiler were running as a daemon, with the 
example of incorporating tools to automatically change code in 
the editor when we make breaking changes to the language. He said 
Jan's work with serve-d was great, but this would probably be 
better and quicker if implemented natively in the compiler.

Razvan said the problem is that we don't support incremental 
compilation. He brought up past work done attempting on dmd as a 
library that encountered problems because of that. Robert said 
that's one reason why moving to a daemon would require a complete 
rewrite. Incremental compilation is a thing, and we should have 
it. He suggested everyone install Android Studio and play around 
with Flutter and Dart. The developer experience is like very good 
crack. Razvan wondered if SDC supports incremental compilation.

We ended this discussion with Walter being open to looking into 
this. Robert said he would email a link to an interesting talk 
about a compiler design that he thinks will lend itself to 
running as a daemon and supporting incremental compilation. He 
emphasized that he wants to still be discussing D with us 40 
years from now and that all of his feedback, even the critical 
bits, should be taken as loving input.

__Bugzilla to GitHub migration__

I then asked Robert about the script for the Bugzilla to GitHub 
migration. He said he planned to set things up so that I could 
run it myself, but he needed to make the time to get there.

__JSON parser__

Robert had recently implemented a quick JSON file parser using 
`SumType`. He'd wanted to see if he could use `SumType` to 
represent HTML/XML/JSON/YAML/TOML. Apart from assigning `void` as 
a value to the sumtype, it worked in ` safe` and was very nice. 
The implementation was only around 150 lines. It took him only 
half an afternoon. `SumType` is really awesome, and we should 
really do something with it. `std.json` works, but could use a 
revamp. We don't have `std.xml` anymore. We don't have `std.yaml` 
or `std.html` or `std.toml`, etc., and those should be in Phobos. 
Átila agreed. We just need someone to write them.


Ali reported that he had finished the new D program at work he 
had [told us about in the November 
meeting](https://forum.dlang.org/thread/citxnklerlvqmybyoaat forum.dlang.org).
It had uncovered a performance issue with `std.file.dirEntries`. As for the
program, he was happy with the end result.

He said he'd used `std.parallelism.parallel` again and speculated 
he's probably among the people who've used it most. He said it 
helps tremendously. It's very simple and everything becomes very 
fast.


Andrei said he had been doing a fair amount of C++ coding at 
work, and it had given him an interesting perspective on things. 
One area in which the D language can do a lot of good is 
simplification. A simpler language is really useful. He'd noticed 
that some of the features in C++ were designed to fight against 
other features that were poorly designed or implemented, and that 
adds complexity.

He suggested that going forward we should consider removing 
limitations of existing features, making them simpler and more 
general. This should be a high-level goal, and new features 
should be targeted at that. Caching template instantiations, for 
example, would be a compiler addition that would be high impact 
toward that end. He'll let us know if he has more such ideas. 
Walter thinks that's a good goal. Andrei said the main thing is 
that we have things that don't work that should (like 
` property`), and things that work that shouldn't. It's a bizarre 
situation, and people latch onto that.

That segued into a brief discussion about removing features. 
Átila said that we can't do that until we have something like 
"Editions" so that we can make non-breaking breaking changes.


Átila said he had been trying to figure out what to talk about 
for DConf Online. He went back to something he was doing a long 
time ago that Andrei had talked to him about, which is a better, 
simpler way of doing reflection. The disparate APIs we have are 
complicated to use. And with all the talk about templates and 
compile times, why not do it using string mixins? He'd started 
working on a library called "mirror", but never finished it 
because the only way to know if the API was good and worked was 
to use it for something real. So he had been trying to write 
another Python wrapper library from scratch using only string 
mixins. It had been relatively easy, but there's no prior art in 
this space, so it's kind of hard to figure out how to do it. He 
thought it would be an interesting talk. He noted that the first 
thing he noticed was how fast the compile times were. (I think 
[his talk turned out to be 
interesting](https://youtu.be/OeCY1QotnRw)).

I brought up a problem I'd had years ago when I implemented a 
mixin-based OpenGL binding for Derelict that could be configured 
via string mixins as a free-function API or as a struct-wrapped 
API (e.g., `glClearColor` vs. `GL.clearColor`). Something was 
causing the struct configuration to take over 10 minutes to 
compile. I could never pin it down, so ultimately gave up. We 
have no good way to debug string mixins. (Atila and I talked a 
bit about this in [our DConf Online Q & A 
session](https://youtu.be/UsIO-b50OAc)). Átila said that 
debugging templates isn't a great user experience either.

Andrei said he and Walter had talked about this in the past, and 
he thinks there's an opportunity there. With string mixins there 
are two stages: one is creating the strings and the other is 
mixing them in. He speculates there's a cost to each side. His 
suspicion was that the creation of the strings was more 
expensive. Walter's idea back then, which Andrei thinks is worth 
revisiting, was that the compiler could easily create the 
reflection for a module/struct/class in one shot, rather than 
assembling it piece by piece. You ask for the reflection, and it 
gives you a struct whose fields are strings representing the 
info. Átila said that's what his library does, and Andrei 
suggested it would be more performant if it were in the compiler. 
Átila's intuition is that a bytecode interpreter for CTFE would 
have more impact on speed.

And anyway, just by mixing stuff in rather than using templates, 
Átila had found the performance improvement surprising. The 
challenging part had been deciding how to structure the code. 
With templates, everything is neat and tidy and clean. If he 
needs to manufacture a function out of the aether, he can put it 
in a template and just instantiate the template, whereas with 
mixins he has to generate the string for the function and then 
put it somewhere.

I noted that Átila's talk was a complement to Steven 
Schveighoffer's. (Steven's talk was [Model all the 
Things!](https://youtu.be/GFvh6Hbc-3k)).


Walter had been working on a long-standing bug with `ModuleInfo` 
which had been around for 10 years. Reading the bug reports on 
it, no one seemed to understand how `ModuleInfo` actually works. 
Part of the problem was a documentation problem. He was going to 
see if he could unstick all of that. This was a barrier to people 
using D and it needed fixing.

He then said that he had noticed in discussions on HN and 
elsewhere a tectonic shift appears to be going on: C++ appears to 
be sinking. There seems to be a lot more negativity out there 
about it these days. He doesn't know how big this is, but it 
seems to be a major shift. People are realizing that there are 
intractable problems with C++, it's getting too complicated, they 
don't like the way code looks when writing C++, memory safety has 
come to the fore and C++ doesn't deal with it effectively, etc.

For us, that's good news. The bad news is that Rust, not D, is 
filling in that gap. He wants to keep plugging away at memory 
safety. That won't help us in the marketing department, but at 
least in the technical department, we can get it there.

Robert thinks Rust has won that game. We're the second person to 
the moon. Put ` safe` on top, disallow taking addresses of the 
stack, don't allow returning `ref`, and don't allow pointer 
arithmetic. That's as safe as we need to be. D's niche is on top 
of Rust and under TypeScript. That's where we need to be. That 
may not be the most popular opinion in the group, but he was 
alone in his room and no one could hurt him. He thinks C++ *has* 
been sinking, but it's probably going to keep sinking until he's 
dead and will never sink completely, but Rust will take that 
over. Rust is also taking over some of the web world because it 
compiles easily to web assembly.

Walter agreed that C++ will never disappear, but he thinks it 
will fade into the background. He appreciates Robert's opinion. 
It's something we need to think about.

Next, Walter said he needed to record [his DConf Online 
talk](https://youtu.be/RO7IJvxtwjQ) and send it to me.

Then he said something else he'd been doing lately was asking 
people to provide specific lists of problems they're having. 
Vague generalizations aren't useful. He needs action items that 
he can fix.

As always, he just has too much work to do. He has to prioritize 
what he's getting done. Looking ahead, he was thinking about a 
built-in sumtype. He wasn't sure about the implementation 
schedule for it, but a spec that is vetted and would work is a 
good thing to have. Don Allen had posted a number of problems 
with ImportC that he needed to look at. He was hoping to fix all 
the low-hanging fruit with it that he could.



The next meeting was a Quarterly meeting, meaning industry reps 
were involved, and took place on January 13, at 14:00 UTC. "D 
frustrations" was a major topic of discussion in that meeting. 
I'll have the summary as soon as I can. Unfortunately, it's going 
to be less detailed than usual. I managed to botch the OBS Studio 
settings once again and ended up with no audio output. My mic 
came through, but that's all (this is the second time I've done 
that with a meeting, and I'm determined to make it the last). 
This means that I'm going to have to rely on help from the 
participants to cobble together a summary. I know several people 
enjoy reading these, and I feel terrible for such a silly 
mistake, so I'll try to gather as much detail as I can.

I would like to remind everyone to continue sending me your own 
frustrations with D and your wishlists for the future 
(social dlang.org). We're going to use this information to help 
guide changes in processes and management and to mark a path 
forward.

I can't provide details at this time, but I can report that we 
have recently taken a big step toward our long-term goal of 
getting a handle on the chaos. Most of the people (everyone?) 
involved found it to be a positive experience. I think I can 
safely speak for them when I say we're looking forward to what 
comes next. At some point, hopefully next month, I'll be able to 
say more about it.

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

A very big problem we have right now is that we are on pretty shaky 
foundations with how symbols are represented at the binary image level 
due to DLL's not be fully implemented in dmd.

Any work for things like incremental compilation must be done with the 
knowledge that the foundations right now are just not there to do this 
reliably cross platform.

I.e. is incredibly easy to run into: 
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4217?view=msvc-170

I believe we are going to have to modify export (and with that removing 
it as a visibility modifier) quite significantly.

In the C/C++ world you can use macros and compiler level defines to swap 
out DllImport and DllExport, or remove it all together. We can't do 
that. Which means we are going to need to make export a whole lot 
smarter if we don't want to run into these issues on Windows.

Sergey <kornburn yandex.ru> writes:

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 The December meeting took place on the 3rd of the month at 
 15:00 UTC. The following people were present:

 * Andrei Alexandrescu
 * Walter Bright
 * Ali Çehreli
 * Dennis Korpel
 * Mathias Lang
 * Átila Neves
 * Razvan Nitu
 * Mike Parker
 * Robert Schadek

Thank you Mike and all D foundation. It was very pleasant read.
I am surprised how many things and details were discussed in an 
hour and a half!

Mike Shah <mshah.475 gmail.com> writes:

On Saturday, 21 January 2023 at 11:25:37 UTC, Sergey wrote:
 On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 The December meeting took place on the 3rd of the month at 
 15:00 UTC. The following people were present:

 * Andrei Alexandrescu
 * Walter Bright
 * Ali Çehreli
 * Dennis Korpel
 * Mathias Lang
 * Átila Neves
 * Razvan Nitu
 * Mike Parker
 * Robert Schadek

 Thank you Mike and all D foundation. It was very pleasant read.
 I am surprised how many things and details were discussed in an 
 hour and a half!

Agreed 100%, these summaries and the transparency into the 
decision making are great!

Adam D Ruppe <destructionator gmail.com> writes:

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 As far as he understood, the only time ` property` has an 
 effect is when you take the address of a function it annotates.

It is when you do typeof(thing.prop), not &thing.prop.

 Walter said that `__traits` is meant to be ugly.

We should revisit this decision. I don't think it ever made 
sense, and especially now with the benefit of hindsight it looks 
like a clear unforced error.

 Robert said that doesn't solve his problem with compile times. 
 He has a project that doesn't use much of Phobos, but compile 
 times still suffer. The compiler is slow.

I'd like to know more about this project....

 He had previously dug into `hasUDA` and it was scary how many 
 recursive expansions he found.

We should also revisit the abstractions here. The more I use 
these the more I've been landing on something like what Steve 
described in the dconf online. It is faster to compile, more 
flexible with runtime reuse, and just generally easier to 
document and use.

Then we can just let hasUDA and friends die.

 That goes to the idea of caching or pre-compiling the template 
 so that

Please note that the compiler does cache templates right now, and 
it takes gigs of memory. A lot of work would have to be done to 
make this good since work not done is still better than work 
unnecessarily done... and if it is cached too aggressively you 
just run out of memory.

If the end result is simple, we ought to be able to discard 
intermediate results, but the current implementation doesn't even 
allow this!

 We don't have [...] `std.html` [...] We just need someone to 
 write them.

Yes, if only some did that 13 years ago and has been continuously 
maintaining it ever since. If only ~someone~ wrote that.

 Something was causing the struct configuration to take over 10 
 minutes to compile.

If you did any string replacements that'd slaughter your 
performance, the ctfe engine is *extremely* bad at this.

In my arsd.jni, I had a string like:

enum code = q{
      PRETEND_MACRO void foo() { implementation; }
};

mixin(code.replace("PRETEND_MACRO", ""));
mixin(code.replace("PRETEND_MACRO", "static"));

Those two simple lines added 30 seconds to the compile time! Just 
copy/pasting it and replacing the pretend macro ahead of time cut 
95% of the build time off. It was astonishing.

You can optimize some of these with mutable buffers, avoid the 
concat operator in ctfe even if it means two passes through the 
data. This helps a lot.

But also just using template mixins tends to work well when you 
know the proper techniques.

ryuukk_ <ryuukk.dev gmail.com> writes:

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 Robert spoke up then to suggest deprecating  property and 
 releasing a tool that removes it from a code base. Then we 
 should apply that tool to create pull requests for all dub 
 packages using  property, and then in a future release, we kill 
 it. Anyone affected by the removal can then run the tool on 
 their own code. He added that we should do this with any 
 feature we decide to remove. This is the modern way of software 
 development: you don't just break someone's code, you break 
 their code and give them a tool to fix it.

I agree with that 100%, perhaps the feature should be built in 
into DUB, it can already detect the compilers and its version, so 
it can do all the heavy lifting already


 Compile times keep getting slower. Why doesn't an LSP 
 implementation come with DMD? Why don't we have a compiler 
 daemon? Why aren't his build times sub one second?

All my projects  fully recompile in around 1s, i am sad when i 
see libraries that tank the compile speed to multiple seconds..

I ended up writing my own runtime and my own std, this is why i 
advocate for language enhancements rather than putting more 
template soup into the std

And i agree even more on the language server, Jan did an amazing 
work with serve-d, but it highlights 2 problems:

- slow to compile, wich makes contributing a pain
- DCD is basically too basic, doesn't even support most D 
features including templates



  SumType is really awesome, and we should really do something 
 with it.


I agree, SumType is a great piece of library, it should be 
promoted as a language feature

 The first involved dub's settings file, settings.json. As he 
 put it, have you ever seen a program that asked you to write 
 its settings using JSON? There had been some favorable 
 responses to the idea of moving to YAML from some core 
 contributors a few years back. It just needed someone to do it. 
 He asked if we were okay with the move. Átila said we probably 
 shouldn't keep JSON, but wondered if YAML was the best choice. 
 What about TOML? This sparked a minor bikeshedding discussion, 
 but there was no major opposition to Mathias's plan. (He has 
 since opened a draft PR. Sönke Ludwig wants to see a broader 
 discussion of this before finalizing it, so I expect Mathias 
 will ask for community feedback at some point.)

I agree, json is not a good file format, it doesn't even support 
comments and is annoying to parse

A simple ini file would be 10x better already, no need 
complicated parsers like YAML or TML



 Robert thinks Rust has won that game. We're the second person 
 to the moon. Put  safe on top, disallow taking addresses of the 
 stack, don't allow returning ref, and don't allow pointer 
 arithmetic. That's as safe as we need to be. D's niche is on 
 top of Rust and under TypeScript. That's where we need to be. 
 That may not be the most popular opinion in the group, but he 
 was alone in his room and no one could hurt him. He thinks C++ 
 has been sinking, but it's probably going to keep sinking until 
 he's dead and will never sink completely, but Rust will take 
 that over. Rust is also taking over some of the web world 
 because it compiles easily to web assembly.


I DISAGREE fully, Rust has not won "that game", there is a 
similar negative sentiment about rust, "too complicated", "too 
hard", "bad syntax", "slow to compile", etc

The future will be many languages, each being best at certain 
domains, we seen it with the rise of Go, doing what it do best 
with the cli/web/server/containers and nothing else

WASM? C/C++ won the game, Abobe is the perfect example, it's not 
simple hello world Rust people are doing, it's full commercial 
projects https://web.dev/ps-on-the-web/

Same with games

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Sat, Jan 21, 2023 at 04:29:28AM +0000, Mike Parker via
Digitalmars-d-announce wrote:
[...]
 __CTFE writeln__
 
 Razvan next brought up [a PR to implement a `__ctfeWriteln`
 built-in](https://github.com/dlang/dmd/pull/12412). It was currently
 stalled and needed Walter's approval. Walter asked Razvan to email him
 about it. He subsequently approved it.

This may seem like a small item, but it's a landmark!!  The first PR for
this was submitted back in 2011 (https://github.com/dlang/dmd/pull/296),
superceded in in 2012 (https://github.com/dlang/dmd/pull/692), revived
in 2016 (https://github.com/dlang/dmd/pull/6101), re-attempted in 2017
(https://github.com/dlang/dmd/pull/7082), submitted in its present form
in Apr 2021 (https://github.com/dlang/dmd/pull/12412), and finally
approved in Dec 2022.  This is monumental!

OTOH, it begs the question, is there any way to improve our present
process so that relatively small features like these don't take 11 years
to get implemented?


[...]

 Ali reported that he had finished the new D program at work he had
 [told us about in the November
 meeting](https://forum.dlang.org/thread/citxnklerlvqmybyoaat forum.dlang.org).
 It had uncovered a performance issue with `std.file.dirEntries`. As
 for the program, he was happy with the end result.
 
 He said he'd used `std.parallelism.parallel` again and speculated he's
 probably among the people who've used it most. He said it helps
 tremendously. It's very simple and everything becomes very fast.

Just wanted to chime in here to say that std.parallelism.parallel is
absolutely awesome, and I've been using it in a few of my projects for
what amounts to instant speed-up "for free".

The original design hit jackpot in making it as easy as possible to turn
a regular foreach loop into a parallel loop: just add .parallel to your
aggregate. This makes it trivial to test the performance gains of
parallelizing any given foreach loop (with independent iterations, of
course). You didn't have to invest a ton of time writing code to
instantiate task managers, task pools, create threads, manage threads,
wait for them to finish, etc.. For highly-specific performance tweaks,
you'd probably want to do all that, but for one-off quick evaluations of
whether a parallel approach is even worth it in the first place, the
design of .parallel is exactly the thing needed. Once you've confirmed
it works, you can, if needed, invest more effort into managing task
pools, etc..  If not, you haven't wasted any effort except writing
`.parallel` -- it's basically zero cost.  And for script-like helper
utilities, .parallel is just the thing you need to get the job done in
the shortest amount of time possible.  No need for anything more
elaborate.


[...]


[...]
 He then said that he had noticed in discussions on HN and elsewhere a
 tectonic shift appears to be going on: C++ appears to be sinking.
 There seems to be a lot more negativity out there about it these days.
 He doesn't know how big this is, but it seems to be a major shift.
 People are realizing that there are intractable problems with C++,
 it's getting too complicated, they don't like the way code looks when
 writing C++, memory safety has come to the fore and C++ doesn't deal
 with it effectively, etc.

The inevitable is happening.  Has been happening, just on a smaller
scale.  But it will only grow.


[...]
 Robert thinks Rust has won that game. [...] Rust is also taking over
 some of the web world because it compiles easily to web assembly.

LDC already compiles to WASM.  It's a crucial first step.  But the
usability level of D in WASM is currently wayyy below what it would take
to win people over.  If we want to win this game, we need to get WASM
support to the point that you could in theory just recompile a D program
and have it work in WASM without any change.  Well, excepting, of
course, stuff that WASM fundamentally can't do.

Currently, you can compile individual functions, but you can't have
main(), you can't use Phobos, you can't use the GC, and you need to
write a lot of JS boilerplate to have your WASM D code interact with
anything outside its own little bubble.  Strictly speaking this isn't
D's problem, but that's cold comfort for anyone who wants to develop for
WASM in D.  Yeah, writing JS and HTML is part-and-parcel of targeting
WASM, but why can't we make our packaging better?  There should be a
tool for auto-generating JS wrappers, perhaps even HTML snippets, so
that a user literally can just write:

	import std;	// OK, maybe import std.wasm or something
	void main() { writeln("Hello, world!");

and get a webpage that prints that message in a browser window without
writing a single line of JS or HTML.  All the JS boilerplate and HTML
tedium should be automatically taken care of, unless the user overrides
something.

Using WASM with D should be on the level of usability of appending
.parallel to your aggregate to get a parallel foreach loop; it shouldn't
require you to write a ton of JS boilerplate and constrict your D code
to the equivalent of jumping backwards with one hand tied behind your
back.


 Walter agreed that C++ will never disappear, but he thinks it will
 fade into the background.

[...]

That I agree with.  My prediction is that C will also gradually fade
into the background and eventually be confined to small niches, but
won't entirely disappear.  Merely become irrelevant.  From my POV, C may
outlast C++ in terms of persistence before becoming irrelevant.  In
spite of all its flaws, C is overall still a cleaner language than C++
and has fewer fundamental design issues that make it unusably
frustrating.


T

-- 
Let's call it an accidental feature. -- Larry Wall

Adam D Ruppe <destructionator gmail.com> writes:

On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
 There should be a tool for auto-generating JS wrappers, perhaps 
 even HTML snippets, so that a user literally can just write:

 	import std;	// OK, maybe import std.wasm or something
 	void main() { writeln("Hello, world!");
 and get a webpage that prints that message in a browser window 
 without writing a single line of JS or HTML.

http://webassembly.arsdnet.net/

Paste in
import std.stdio;
void main() { writeln("hello world"); }

to the box on that page

and get
http://webassembly.arsdnet.net/usertemp

Webassembly is a trash target but like been there done that.

Of course there are some caveats in what works, there have been 
come contributions coming in from hipreme recently to extend it a 
lil.

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Mon, Jan 23, 2023 at 08:43:03PM +0000, Adam D Ruppe via
Digitalmars-d-announce wrote:
 On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
 There should be a tool for auto-generating JS wrappers, perhaps even
 HTML snippets, so that a user literally can just write:
 
 	import std;	// OK, maybe import std.wasm or something
 	void main() { writeln("Hello, world!");
 and get a webpage that prints that message in a browser window
 without writing a single line of JS or HTML.

 
 http://webassembly.arsdnet.net/
 
 Paste in
 import std.stdio;
 void main() { writeln("hello world"); }
 
 to the box on that page
 
 and get
 http://webassembly.arsdnet.net/usertemp

Ahahahaha...  just like Adam to have already dunnit while I'm still
twiddling my fingers wondering how to go about doing it. :-D  Now all we
need is to package your little page up into a dub package or something
(personally I prefer just a tarball) and we're good to go. :-D


 Webassembly is a trash target but like been there done that.

Yeah TBH after dabbling with it a little I realized just how much it was
still dependent on JS to do the heavy lifting.  You can't even pass
strings across the JS/WASM boundary without truckloads of JS
boilerplate.  The C-like API isn't officially part of the WASM standard
yet, and they're still trying to figure out how GC might work. As far as
I'm concerned, it's still early adopter tech, not yet stable enough for
me to invest in.


 Of course there are some caveats in what works, there have been come
 contributions coming in from hipreme recently to extend it a lil.

Nice.  Can it handle WebGL yet?  I betcha that'd be the second question
a newbie to D would ask after asking about WASM. :-P


T

-- 
I see that you JS got Bach.

Hipreme <msnmancini hotmail.com> writes:

On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
 On Mon, Jan 23, 2023 at 08:43:03PM +0000, Adam D Ruppe via 
 Digitalmars-d-announce wrote:
 On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
 There should be a tool for auto-generating JS wrappers, 
 perhaps even HTML snippets, so that a user literally can 
 just write:
 
 	import std;	// OK, maybe import std.wasm or something
 	void main() { writeln("Hello, world!");
 and get a webpage that prints that message in a browser 
 window
 without writing a single line of JS or HTML.

 
 http://webassembly.arsdnet.net/
 
 Paste in
 import std.stdio;
 void main() { writeln("hello world"); }
 
 to the box on that page
 
 and get
 http://webassembly.arsdnet.net/usertemp

 Ahahahaha...  just like Adam to have already dunnit while I'm 
 still twiddling my fingers wondering how to go about doing it. 
 :-D  Now all we need is to package your little page up into a 
 dub package or something (personally I prefer just a tarball) 
 and we're good to go. :-D


 Webassembly is a trash target but like been there done that.

 Yeah TBH after dabbling with it a little I realized just how 
 much it was still dependent on JS to do the heavy lifting.  You 
 can't even pass strings across the JS/WASM boundary without 
 truckloads of JS boilerplate.  The C-like API isn't officially 
 part of the WASM standard yet, and they're still trying to 
 figure out how GC might work. As far as I'm concerned, it's 
 still early adopter tech, not yet stable enough for me to 
 invest in.


 Of course there are some caveats in what works, there have 
 been come contributions coming in from hipreme recently to 
 extend it a lil.

 Nice.  Can it handle WebGL yet?  I betcha that'd be the second 
 question a newbie to D would ask after asking about WASM. :-P


 T


I was going to wait a little bit on that announcement. But yes, 
Hipreme Engine has already been completely ported to WASM. File 
loading, rendering with my abstraction, audio playing, 
image/audio decoding, input system, I've got pretty much 
everything working. WASM only changed in my engine how the file 
loading is handled internally. An example, It sends D delegates 
to JS execute when things are complete, so, there isn't anymore a 
sync API for loading files.

I have used arsd.cgi for making it easy to any D programmer host 
it with dub. I have posted on Learn like yesterday how to 
integrate the custom runtime with any dub project too, which is 
how I'm using to build for my engine.

The list of features being supported are:

- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding


Unsupported features:

- static this/~this (should be easy to implement though, my 
engine has no need to do that, specially since it uses a lot of 
DLL for Android and Xbox and static this is quite buggy for it 
anyway)
- try/catch
- fibers

The problem on try/catch/fiber are the same. They need stack 
unwinding and from what I've looked, this implementation needs 
compiler developers to write a little of assembly to get this 
working, as I have no idea on how that works, I can't implement 
that.

I believe this covers like 90% the usage of one using the 
druntime.

I honestly don't care about throw/catch. Specially for gamedev 
which is my aim, the code doesn't need to "protect" from itself.

That being said, if one is not using Hipreme Engine and is using 
a lot of standard library, this one would need to implement a lot 
of it. Hipreme Engine implements a minimal phobos (as I don't 
implement the entire libc) for being used. Needless to say, some 
modules from phobos didn't need to adapt to WASM, so, 
`std.algorithm` and `std.traits` are being used from upstream.

std.math was possible to copy/paste without too much work to do 
(A matter of 5 lines I think).

I'm also using arsd.ttf to runtime create text textures, a 
library which does not uses any of my modules, no bug was found 
on it, so, this is mostly a matter of giving a little of effort 
and everything can be done.

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 1/23/23 12:06, H. S. Teoh wrote:

 `.parallel` -- it's basically zero cost.  And for script-like helper
 utilities, .parallel is just the thing you need to get the job done in
 the shortest amount of time possible.  No need for anything more
 elaborate.

Yes! :)

As a heads up to those who haven't tried it yet, there are cases that 
may benefit from reducing the work unit size from its default value of 100.

Especially when it's about file processing and there are a few files 
that take disproportionate amount of processing time, then the thread 
that is working on the largest file(s) would be holding on to 99 others 
to process them later in serial fashion. This may happen when the other 
e.g. 20 threads have already finished their tasks.

So, I recommend experimenting with smaller work unit sizes; I currently 
use 1 for such file processing. Something like this:

   auto tp = new TaskPool(totalCPUs / 2);   // Thread count
   foreach (e; tp.parallel(elements, 1)) {  // Work unit size
     // ...
   }
   tp.finish(); // Don't forget

as seen here:

   https://youtu.be/dRORNQIB2wA?t=1692

Ali

Siarhei Siamashka <siarhei.siamashka gmail.com> writes:

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 Robert thinks Rust has won that game. We're the second person 
 to the moon.

Do you mean second to last? The safety offered by D language 
currently only looks good when compared to C/C++, but is worse 
than pretty much any of the other popular/mainstream languages. D 
language even did not invent memory safety, because the other 
safe languages existed long before it (such as Python, etc.).

The strong point of D language is a convenient syntax combined 
with full native speed of compiled binaries. And also compilation 
speed for those who care about it. But the safety is not exactly 
great. And compatibility breaking habits are also bad. D can't 
realistically compete with Rust on the safety front and with 
C/C++ on the compatibility front.

 Put ` safe` on top, disallow taking addresses of the stack, 
 don't allow returning `ref`, and don't allow pointer 
 arithmetic. That's as safe as we need to be.

I like this proposal. Will it actually happen?

Walter Bright <newshound2 digitalmars.com> writes:

On 1/23/2023 11:21 PM, Siarhei Siamashka wrote:
 But the safety is not exactly great.


overflows.

If you use  safe, and the GC for allocations, it is just as memory safe as
Python.

Johan <j j.nl> writes:

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
 The December meeting took place on the 3rd of the month at 
 15:00 UTC. The following people were present:


 Razvan noted that simplifying the language is part of our 
 vision, and this seems like a good candidate. Walter agreed. 
 Dennis suggested going through DRuntime and Phobos to look at 
 all instances of ` property` and seeing if they could be 
 removed. Walter agreed.

Is there a document describing cases where removal of ` property` 
does not lead to an error but does lead to a change in behavior 
of code?

We are considering a blanket removal of 3000+ instances of 
` property`. The resulting compile errors I can fix (unless they 
happen in speculative instantiations, they may be harder to track 
down), but I am especially worried about changes in behavior that 
do not lead to compile warnings/errors.

Thanks a lot,
   Johan

Paul Backus <snarwin gmail.com> writes:

On Saturday, 28 January 2023 at 13:04:33 UTC, Johan wrote:
 Is there a document describing cases where removal of 
 ` property` does not lead to an error but does lead to a change 
 in behavior of code?

 We are considering a blanket removal of 3000+ instances of 
 ` property`. The resulting compile errors I can fix (unless 
 they happen in speculative instantiations, they may be harder 
 to track down), but I am especially worried about changes in 
 behavior that do not lead to compile warnings/errors.

Given that the only thing ` property` actually does is change the 
result of `typeof` in certain situations, the behavior changes 
will probably be things like the following:

```d
static if (typeof(foo.bar) == T) {
     // foo has a `T bar` property
} else {
     // doesn't have it
}
```

Currently, if `foo` has a ` property T bar();`, this code will 
take the first branch. If ` property` is removed, it will take 
the second.

Walter Bright <newshound2 digitalmars.com> writes:

On 1/28/2023 5:04 AM, Johan wrote:
 Is there a document describing cases where removal of ` property` does not
lead 
 to an error but does lead to a change in behavior of code?

No.

 We are considering a blanket removal of 3000+ instances of ` property`. The 
 resulting compile errors I can fix (unless they happen in speculative 
 instantiations, they may be harder to track down), but I am especially worried 
 about changes in behavior that do not lead to compile warnings/errors.

It's been a while, but I think the only difference is if you're taking the 
address of a property. Without the  property, the address of the function will 
be taken. With  property, the address of the return value will be taken.

This will affect inference, such as `auto x = &s.foo;`

That will likely lead to type mismatch errors further down the line, but I
can't 
guarantee it.

The best approach I can recommend is to remove the  propertys a handful at a 
time, checking them into git, and running your test suite to check for any 
failures. This will make `git bisect` invaluable in tracking down the cause of 
any errors that are missed by the test suite.