D Language Foundation April 2024 Monthly Meeting Summary

[Mike Parker]

The D Language Foundation's monthly meeting for April 2024 was 
held on Friday the 12th. It lasted an hour and 20 minutes.

## The Attendees

The following people attended:

* Paul Backus
* Walter Bright
* Jonathan M. Davis
* Timon Gehr
* Dennis Korpel
* Átila Neves
* Mike Parker
* Robert Schadek

## The Summary

### Item 1: Phobos v3 CI

Jonathan said Adam Wilson had set up [the Phobos v3 
repository](https://github.com/LightBender/phobos) to use dub. 
That wasn't a big deal since we weren't distributing it yet, but 
we hadn't yet agreed on how it would be built for distribution. 
Although there wasn't a lot of code there yet, it would be nice 
if the CI could run the tests on what was there so that we could 
catch breakage.

He'd tried to add the dub test stuff to the normal makefile 
targets to get it to run as part of the CI. It worked locally on 
his machine, but most of the test runners didn't have dub, so it 
didn't work in the repo. BuildKite did have dub, but it was 
failing there, too. He said that either the test runners needed 
to be updated to work with dub, and he didn't know how to do 
that, or the Phobos v3 build needed to be altered so it wasn't 
using dub.

Dennis said he had set up a `dub.sdl` to build DMD with dub and 
the CI had failed there, too. His solution was to make his own 
workflow, [a separate YAML file for GitHub 
Actions](https://github.com/dlang/dmd/blob/master/.github/workflows/build_with_dub.yml) which used the standard D community setup that installed everything, including dub. He said he also didn't know the details of all the CI workflows or how to integrate this neatly, so he was just kind of improvising.

Jonathan said he'd tried to add the dub test stuff just to get it 
in there and building without mucking with all the makefile 
stuff. He expected that long term we wouldn't want to be using 
dub here, but he didn't know. He'd just wanted to get it working 
with minimal effort without spending time on building stuff he 
wasn't familiar with.

Dennis suggested it might be possible to just use `dmd -i -run` 
with a module that imported all the Phobos modules. That would 
probably work since it was just a collection of source files.

Jonathan said he would have to dig into that and figure it out.

### Item 2: @live

Walter said that [the ownership/borrowing 
system](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/), `@live`, was about two-thirds implemented. It had sat around for years with little or zero interest. He'd set it aside because of all the DIP 1000 bugs. DIP 1000 was required for it to work.

However, something had changed in the industry. The government 
had said that programs should be written in memory-safe 
languages. This was causing a shift away from C++ toward Rust. We 
didn't have a story there. We couldn't really say we were 
memory-safe, although we were 90 or 95% there with DIP 1000.

We had a preview switch that turned on the `@live` checks, but he 
felt that was preventing people from using it. It had taken him a 
while to figure out which switch it was, and as he was talking 
about it here he couldn't remember the name. Dennis said it was 
`-preview=dip1021`. Walter said that was it, and the issue was 
that DIP 1021 was a different DIP that wasn't about `@live`, but 
it was the switch that enabled it.

He said that `@live` didn't change any semantics. It only added 
an extra layer of checks on functions tagged with `@live`. So 
right now you could mark functions with `@live` all you wanted 
and nothing would happen until you turned the switch on. He felt 
the switch was a pointless barrier and should be made the default.

Historically, there had only been 15 or so bugs for `@live` and 
all but one had been fixed. In fixing a couple of them recently, 
he'd discovered a couple more gaps in what the ownership and 
borrowing system did. He was working on fixing them. He proposed 
that we turn on `@live` by default so people might be more 
inclined to try it and file bug reports on it.

In the long run, the point was that we needed D to be a 
memory-safe programming language. That was the most important 
thing. He noted that there had been repeated requests to do null 
tracking. There had been constant complaints about class 
references being default initialized to null, then someone would 
try to call a member function and get a segfault. Walter still 
believed that wasn't actually a problem, but the `@live` code 
could be enhanced to do null tracking. If it were on by default, 
then he'd be willing to make the enhancement. He'd implement it 
such that it would only trip if it were sure that a null 
reference was being made, and wouldn't trip in ambiguous cases.

He thought this was the last step to being able to say that D was 
a memory-safe language, and we'd be able to do it without the 
ugliness of Rust. He thought Rust was ugly to look at and that 
memory-safe code didn't need to be ugly.

Timon said that maybe we could enable it, but his issue was that 
`@live` by itself didn't improve memory safety. Walter said he 
knew that was Timon's position, but he didn't understand it. He 
said that the cases it was supposed to work on, it *did* work on. 
No matter how convoluted your code, it correctly detected if 
you'd borrowed something or not and would give you errors if you 
didn't dispose of it before the end of the function. It did what 
it was supposed to do.

As Walter recalled, Timon wanted two kinds of 
pointers---ownership/borrowing pointers and GC pointers. Walter 
had objected to that based on how disruptive it would be to how 
the compiler worked internally.

He noted that Microsoft had created Managed C++, which had two 
kinds of pointers---GC pointers and non-GC pointers. Though they 
still maintained it, it had vanished from the conversation. He 
considered Managed C++ and their approach to be a failure because 
of it.

Timon said the general issue was that `@live` wasn't properly 
modular. It only added some checks. It didn't ensure invariants. 
To improve memory safety, you needed a type system to ensure 
invariants that improve memory safety. He thought we did have a 
memory-safe language and the best way to write memory-safe code 
today was to disable DIP 1000 and use the garbage collector. DIP 
1000 introduced additional cases of memory unsafety, so just 
disabling it and using the GC with `@safe` would enable memory 
safety.

Walter said it had been brought up before that DIP 1000 didn't 
work. Several bugs were filed. He and Dennis had fixed a long 
list of them and hadn't yet found one problem with DIP 1000 that 
couldn't be fixed.

Timon said that was a reflection of the current state. 
Eventually, maybe enabling DIP 1000 and using the GC when it 
didn't work would be the way forward. But `@live` didn't do 
anything in `@safe` code because `@safe` code was already memory 
safe.

Walter said `@safe` did not guarantee memory safety. What `@live` 
did was let you know if you malloced a pointer and never freed 
it. DIP 1000 couldn't help with that. Timon said you couldn't 
call `malloc` in `@safe` code, so that wasn't the context. Walter 
said he understood that D was memory-safe if you GC'ed 
everything, but we couldn't GC everything and have a systems 
programming language. To have memory safety and be a systems 
programming language, you had to track where the pointers came 
from and where they went. You couldn't free a pointer twice.

Timon said you needed to know those things, maybe, but `@live` 
didn't add this to `@safe`. It would do those checks, but it 
didn't ensure invariants. It wasn't because of bugs, but because 
it was a function attribute.

Walter said it worked within the function. Within the function, 
everything was checked by the ownership/borrowing rules and it 
worked. If you malloced a pointer twice, it would give you an 
error. If you malloced a pointer and didn't free it, it would 
give you an error. If you malloced a pointer and freed it twice, 
it would give you an error. If you malloced a pointer, freed it, 
and then used the pointer again, it would give you an error.

Timon said he agreed, but for example, C++ would give you a 
compiler error if you assigned an integer to a pointer. That 
didn't make it memory-safe. Walter said he didn't understand what 
was memory-unsafe about `@live`. Timon said it didn't improve 
safety guarantees. There was no sound checking. Walter said it 
guaranteed that you had to free anything you malloced.

Timon said you could use aliasing in some other part of the 
program. Walter said the more of your code you marked as `@live`, 
the more checking you would get. It was up to the programmer to 
decide which functions were checked. He noted that even Rust 
didn't have memory safety everywhere. Anything marked as unsafe 
wasn't checked.

Dennis said the premise of `@live` was that it added safety. That 
was just false. We already had a safe language per the spec if 
you ignored the implementation bugs, via `@safe` and the garbage 
collector, but you could do manual freeing. As the language was 
defined, manual freeing couldn't be annotated `@safe`.

So the argument that could be made for `@live` was that it made 
manual freeing possible in safe code. To do that, you had to 
properly prove that it satisfied the constraint that you couldn't 
call `free` in the wrong place and corrupt memory. With the 
current design, that wasn't the case. There were cases in `@safe 
@live` code where you could free a pointer allocated with a 
different allocator and have memory corruption that way, or in 
other cases where you called a non-`@live` function from an 
`@live` function and it would do something.

So with the current definition of `@safe @live`, it didn't add 
any safety. It only added checks to catch some mismatched 
`malloc` and `free` pairs. It didn't add to which code was safe 
code. We already had `@safe` for the garbage collected/stack 
allocated part of D, but not for the malloc/free part. There was 
a whole discussion to be had about how we could do that.

Walter said the malloc/free part was critical because that was 
part of what D was. If you couldn't do malloc/free, then...?

Dennis said it didn't have to be done by `@live`. It could be 
done by a container library or something. Walter said it 
couldn't. Dennis said that we should then explore ways to do it. 
He said Paul was working on that now, how to use allocator 
interfaces to create safe data structures.

Paul said that Walter had once written that C's biggest mistake 
was conflating arrays and pointers. When you passed an array to a 
function in C, the information about its length was discarded. 
Paul thought the fundamental issue with `@live` was a very 
similar mistake: if you passed a pointer from an `@live` function 
to a non-`@live` function, then all of the information about its 
ownership status was discarded. That meant if you wanted a 
memory-safe program rather than just a single memory-safe 
function, then everything had to be `@live` or it wouldn't work. 
The consequence of that was that you'd then have to cut yourself 
off from the entire existing ecosystem of non-`@live` code and 
start from scratch.

Walter said he didn't understand why. You could incrementally add 
ownership/borrowing checks to your code where and when you 
wanted. If you didn't add `@live`, you didn't get the checks. He 
didn't understand how you could get a memory-safe language just 
by fiddling with the allocators. You had to solve the problem.

Paul said it wasn't by fiddling with the allocators, but by 
having the containers do the ownership/borrowing checks. By using 
both `scope` (DIP 1000) and `@system` variables (DIP 1035) 
together, it was possible, ignoring implementation bugs, to write 
containers that manually allocated and freed memory and were safe 
because they used runtime checks to ensure that pointers could 
only be freed when they were not borrowed or aliased.

He had written code that did this. He had a work-in-progress 
implementation of a unique pointer in D that used these kinds of 
checks. There were some UX issues with it. You had to use 
callbacks in places. If you wanted to prevent references from 
escaping, you could pass a scope reference or pointer down the 
stack, but if you returned one up the stack, then it was game 
over. It could escape and there was nothing you could do about 
it, so you had to use callbacks to access the contents of the 
container, meaning either a function that you passed a lambda to 
or an `opApply`.

But it did work, modulo implementation bugs, and it worked using 
features that were already designed and partially implemented. 
And it worked in a way that was compatible with the entire 
existing ecosystem of D code, including existing `@safe` code, 
and did not require you to incrementally transition your entire 
program over to this new set of semantics to reap the benefits.

Walter said that was what C++ did. If you stuck with the C++ 
library, your memory was safe. But that wasn't acceptable. That 
just hadn't worked out in the real world.

Paul said that C++ had a unique pointer and a shared pointer, but 
it had no way to prevent you from holding onto a pointer to the 
memory managed by those objects and using them after that memory 
had been freed. With DIP 1000 and `@system` variables, it was 
possible to prevent `@safe` code from doing a use after free like 
that.

Walter asked, "How about failure to free?" Paul said that was the 
halting problem. Your program could enter an infinite loop and 
never call `free`. Walter brought up Rust, and Paul said Rust 
didn't do that. Rust allowed memory leaks, but they'd free memory 
in their destructors, so it was as reliable as their destructors 
were.

Walter said he took issue with that. When you reached the end of 
a function in Rust and had an owned pointer that hadn't been 
disposed of, you got an error. You got an error in `@live` 
functions, too, and he believed you got the same error in Rust. 
You couldn't just have an owner that ran off the end of the 
function. You had to do something with it.

Timon said that Rust had multiple pointer types. One was the 
standard pointer with the star. Those couldn't be accessed in 
safe Rust code at all. Those were the pointers that you malloced 
and freed. The safety of those operations was ensured by their 
library implementation. The users only got borrowed pointers out 
of that, and those pointers were returned before those library 
containers got destroyed. It wasn't clear-cut what was the 
library and what was the language, but that was what it did.

Walter thanked Timon for the explanation but said you still had 
to check that. He didn't think the language, by using RAII, was 
completely able to check that stuff. Timon said it had the borrow 
checker. It didn't check on plain pointers. `@live` checked on 
plain pointers. In Rust, plain pointers were unsafe territory.

Robert said everyone was wrong and were all talking past each 
other. Any academic arguments about this were irrelevant, and 
Walter's definition of a safe language didn't match the marketing 
hype of all the other safe languages. The biggest complaint Rust 
got as a memory-safe language was that it was too complicated. 
And if we had to do callbacks... Javascript, Flutter, and C# 
basically invented an async syntax to avoid callbacks because 
jQuery or JavaScript callbacks the way node.js did them was 
terrible.

We had to make it simple. If you had to know what a `@system` 
variable was, or a container, or had to write a callback, it was 
dead on arrival. And if it was so easy to get around the `@live` 
checking to call a function that wasn't marked `@live`, then we 
weren't adding anything. He thought the term "systems programming 
language" was also not what people wanted. There were always 
places where you had to do something unsafe to map a file to a 
CPU register or something, but 99.9999% of the time, nobody 
wanted to handle a pointer. At least, he would have never met 
anybody or hired anybody who wanted to shuffle pointers around. 
The world at this point was ruled by Python, and they didn't even 
have that concept.

He reiterated that we needed to make it simple. If he had to know 
`@system` variables and functions annotated with `@live`, then 
no. He was just going to tell the person working on his project 
not to take the address of that thing, just pass a reference 
down, or make it a class, or a global array, and have a nice day.

Jonathan said that DIP 1000 alone already increased complexity 
considerably. That didn't mean we shouldn't have it, but he'd 
specifically avoided using it in anything he'd dealt with because 
it was too hard to understand as it was. So if we were worried 
about people being able to understand this so that they could 
easily use it, then DIP 1000 on its own was already too much.

For some people, the easiest was just going to be using the GC 
and not worrying about the rest of it. For a lot of stuff, that 
would be enough. He didn't know what we needed to do about 
`malloc` and `free`. He was fine just saying you'd have to use 
`@trusted` with that stuff. He didn't know enough about all of 
this to say if we needed `@live` or not, but the complexity was 
already pretty high. He thought we'd have a problem getting 
people to actually use it no matter how good it was.

Walter said that having `@live` was a marketing point. His 
impression was that a lot of people who wrote Rust code didn't 
actually want to deal with the borrow checker, so they would just 
mark everything unsafe and then brag about their program being in 
Rust and everyone was happy with it. He thought that was a 
perfectly reasonable way to program: just don't worry about any 
of this stuff and write your code the way you want. But for the 
people who demanded this sort of protection, we needed to have a 
mechanism for it.

Átila thought `@live` had a few issues, but one of them was the 
focus on `malloc` and `free`. Nobody should be calling those 
anyway. Why would you be doing that? Just use a smart pointer, a 
container, or something. We needed to focus on whatever language 
changes were necessary to enable writing those types in a way 
that they couldn't be escaped, and not focus on whether they 
freed a thing or not.

Walter said he never understood smart pointers in C++. The layers 
and layers of templates with those things in C++ gave him a 
headache. So he was with Robert on that. He wasn't interested in 
the complexity.

Timon said he could accept the argument that Walter wanted to 
make a marketing point, but then we'd attract people who were 
fine with engaging in some sort of cargo cult. Walter said a 
cargo cult was chasing a false god. `@live` would actually work. 
Timon said it would do the checks, but it wouldn't give you the 
guarantees. He said Walter had started the conversation by 
talking about why the government wanted people to use memory-safe 
languages. Timon thought they were talking about the guarantees.

Robert said he'd bet Timon drinks forever that they weren't 
talking about guarantees. The word "should" was probably in there 
somewhere. If you had to build a drone and you didn't have the 
budget in your embedded CPU... There was always going to be that 
weird little thing that wasn't memory-safe because of reality.

Timon said that if you wanted to have `@live` as a linting tool 
for `@system` functions, that was fine. We could market it that 
way.

Robert thanked him. He said we should have safe by default. If 
you wanted a footgun, then maybe `@live` was a tool that would 
help you shoot off only one toe rather than the whole foot.

Timon said there was some wiggle room. Depending on how exactly 
we developed `@live`, either it didn't improve safe capabilities 
or it made it safe and sound.

Robert disagreed. If you could have more checks to give you more 
checks that were technically correct, then you had more. It 
wasn't removing anything at that point.

Timon said that was exactly right, you could have more checks. 
That was one of the options. But then that meant that less code 
was accepted. And the code that wasn't accepted was not 
memory-unsafe, because it was in an `@safe` function in the past.

Robert said it would still be theoretically possible to write 
unsafe code, but in practice, most things would be stopped by the 
hammer.

Paul said if the purpose of `@live` was to exist for marketing 
and box-ticking, then he couldn't make an argument against it. 
But he wanted to point out that there were a lot of things on our 
TODO list, a lot of ongoing projects, things we could be spending 
our time and effort on. Maybe a feature whose only purpose was to 
tick a box on a marketing checklist wasn't the best place to 
allocate our resources if we had to choose.

Walter said he'd set it aside for four years to work on other 
issues. He had thought ImportC was a much more important project, 
and he still believed it, but it was working now. There was also 
the long list of DIP 1000 problems, and he thought that was under 
control now. But with the government declaration, he believed we 
needed something to reassure people that they could write 
memory-safe code in D and that they didn't necessarily have to 
use the GC to do it.

Paul said he would question if DIP 1000 was really taken care of. 
He had been working on code that attempted to rely on it and had 
run into some serious issues with it. In its current state, he 
thought nobody should be using it for anything outside of 
experimental or toy code.

Walter asked if Paul had reported the issues he'd encountered. 
Paul said he had. He'd talked to Dennis about some of them, and 
Dennis had told him that DIP 1000 had been put on pause until 
editions were figured out.

Dennis said that fixing those issues was hard when some of the 
existing BuildKite projects were already relying on those DIP 
1000 quirks. It was hard to navigate around the breakage with 
those fixes. Editions would help, but that was kind of slowly 
trotting along.

Paul thought we should remove any BuildKite tests that relied on 
DIP 1000. It was an unstable feature. If you depended on an 
unstable feature, your code was going to break. We should not and 
could not guarantee that code would continue to build.

Dennis said we had encouraged people to use DIP 1000 for the new 
safety. If they had put in all that effort and then we just 
pulled the rug out from under them... He said it was used 
extensively in the Mir container types.

Paul said it had been a mistake to encourage people to use it. We 
should just say we're sorry. The longer we waited to bite the 
bullet, the worse it was going to be.

At this point, I suggested we table this topic for future 
discussion at a planning session or something. Átila was in 
Seattle, and he and Walter were going to talk about it that 
evening. He didn't expect they'd resolve anything, but he hoped 
to make progress. I asked them to let me know when they were 
ready to call a broader meeting about it.

__Addendum__

Walter said that Robert had previously pitched suggestions on 
several features to remove or block in `@safe` code and asked 
Robert to send him a list of all of them.

Átila recalled that he'd posted something about this in the 
forums and that Paul had replied with some issues about it, but 
he couldn't remember the details. Paul said that whether we ended 
up heading in Robert's desired direction of making `@safe` more 
restrictive, or the current direction with DIP 1000 and patching 
all the holes with it and `@safe` by adding new features, either 
way was going to be disruptive and break existing code.

He said that one of the things he liked about D was its power and 
expressiveness. If the decision were up to him, he'd choose the 
direction that made it more powerful and expressive rather than 
less. He emphasized that this was just his opinion and he didn't 
speak for everyone. Ultimately, the final decision would be with 
Walter and Átila.

He added that he could see the merit in Robert's position. In 
working on an `@safe` container library and implementing code for 
the callback API, he could see how ugly it was. It worked, but it 
wasn't pretty. He would love it if there were a way to make it 
pretty without a ton of complexity.

I reminded everyone that part of our vision statement was "to 
enable the realization of ideas by shifting the way programmers 
think." That was our yardstick. If any of this stuff aligned with 
that, then we should continue considering it. Otherwise, we 
should discuss if we really needed it. I asked everyone to keep 
that in mind since we'd all gone in on adhering to a vision 
statement.

Before we moved on, Walter let Timon know that although he was 
arguing with Timon on this, he appreciated Timon's perspective 
and insight, and valued his input. Timon said he wasn't arguing 
to be annoying, but because there was a difference of opinion. 
Walter just wanted to make sure Timon didn't get the wrong 
impression and think his opinion wasn't valued.

### Item 3: Tuple unpacking

Timon said that since DConf Online, he'd gotten tuple unpacking 
to pass the compiler tests. Compilation tests now sometimes 
failed in different ways, but the others were passing. Tuple 
unpacking now worked inside functions and foreach statements.

### Item 4: DConf '24 updates

I told everyone that I'd abandoned my hopes to find a sponsor for 
BeerConf at DConf this year. The per night cost for a pub hire 
was prohibitively expensive. Last year had been much more 
expensive than 2022, so it wasn't feasible to do it then. This 
year things were even higher. The cheapest we could find was 
£5500 for three nights. If I were going to ask any D shops for 
that kind of money, it would be much better spent if we put it 
into speaker/staff reimbursements. Especially since travel and 
lodging expenses were up significantly more this year over last 
year.

I explained that we had a minimum revenue target every year to 
cover at least 40% of the reimbursements. Symmetry covered the 
rest as part of their overall budget and typically expected to 
pay no more than 60%. Ideally, we'd be able to pay 100% of 
reimbursements from revenue, but that had never happened.

(__UPDATE__: Later, I was contacted by an anonymous donor looking 
to sponsor BeerConf this year. The donation was enough to cover 
one night, so on September 17th, we'll be able to have a few free 
rounds at [the Trinity Bell on Mitre 
Street](https://dconf.org/2024/index.html#beerconf), not too far 
from the venue. If you're there, please raise a glass to our 
anonymous donor!

Additionally, we received a significant amount of funding from 
Weka, with additional support from Decard. I'm also expecting to 
finalize some support from Funkwerk soon. With this support, we 
were able to significantly exceed our minimum revenue target, 
which in turn allowed us to set the General registration rate to 
the Early-Bird rate. Massive thanks to Weka, Decard, and Funkwerk 
for their support!)

Next, I noted that all expenses were up this year. The venue was 
more expensive because we were hosting the conference in 
September. That wasn't not part of peak travel season, but spring 
and fall were peak conference seasons. Other costs were up, too, 
due to general inflation. Even the cost of the swag was up.

Because of this, in a meeting with the Symmetry DConf liaison and 
our event planner, we discussed the idea of eliminating all the 
swag except the t-shirts. I'd heard from some people that they 
ended up losing or discarding their bags, and some regular 
attendees had asked me if we could do something other than coffee 
mugs.

I asked everyone what they thought: should we just go with 
t-shirts only? Walter said he had the impression that the 
t-shirts were all that most people cared about anyway. Jonathan 
said he used the mugs, but he had a ton of mugs in general so 
wouldn't miss them. Robert said his wife would be happy he wasn't 
adding another mug to the cupboard. He liked them, but if he 
wanted another D mug, he could just order it online. I noted that 
most of mine had been broken, but I didn't know if I even had any 
of the swag bags anymore. I might have thrown them out.

In the end, no one objected to having t-shirts only. So we'll 
give it a try this year and see what the feedback is.

### Extra: Editions/safe-by-default

Átila said he'd been reviewing feedback on an email thread about 
his editions proposal. The original idea had been that editions 
were to be opt-in to avoid breakage. The default would be to 
always compile old code and only switch to an edition when it was 
part of the module declaration. But the majority of the feedback 
was that the compiler should always use the new edition and old 
code should be compiled via a compiler switch.

He was stuck on how to proceed. If he abandoned the original plan 
and went with always using the latest as default, then why should 
we even have the edition attribute for the module declaration? At 
that point, since we'd require a compiler switch to compile old 
code, why not just rely on compiler switches for the editions? He 
also felt that if we went with the latest editon as the default, 
then we'd be defeating our goal of avoiding breakage, which was 
the whole point of editions in the first place.

Jonathan said that the advantage of the module declaration was 
that you could just look at the code and know which edition it 
was intended to work with. Then the purpose of the compiler 
switch would be just to set what the default edition was.

Átila noted that we relied on compiler switches for previews, and 
it turned out that people rarely used them and complained anyway.

Jonathan said he agreed with those who insisted we needed to 
default to the latest edition if we didn't want this to be a 
mess, and noted that was going to require some support in dub. If 
we didn't do that, then we'd just end up with people compiling 
with the default old edition and complaining that we didn't use 
the latest one by default.

Átila said they might do that, but they also might complain 
because their old code broke with the default edition and they 
had to use a switch to make it work. We just didn't know. 
Jonathan said if the latest wasn't the default, we'd be punishing 
people who were trying to do the right thing by shoving them into 
the old language by default.

Átila said he just wasn't sure what to think of this or what to 
propose to the community at this point. He understood the 
arguments on both sides, but he didn't know which was the best 
way forward. Jonathan noted that Adam liked to point out that no 
other language defaulted to the oldest version with this stuff. 
Átila countered with C++.

I suggested that a way to break the logjam might be to have a new 
module declaration. Then when the compiler saw the old `module 
foo`, it would use the old edition, but the new-stye declarations 
would trigger the latest edition.

Átila said that was the proposal he put forth. I clarified that I 
wasn't talking about an annotation. The problem with that was 
that you had to tell people that they couldn't get new features 
unless they annotated the module declaration. I was talking about 
a completely new keyword. Tutorials, docs and such would be 
updated to teach the new keyword instead of the old `module`. 
Then it would become "all new D code uses this module 
declaration" rather than "you have to use this annotation on your 
module declaration to get the newest features".

Dennis said he thought that only new features that introduced 
breaking changes would require editions. Non-breaking features 
wouldn't require you to have editions in your module. Átila said 
that was the case. Rust backported non-breaking features, too, so 
that was fine. But something like safe-by-default would have to 
be in an edition.

Átila noted that since he'd been stuck with the editions 
proposal, he'd written a safe-by-default DIP. He said he'd send 
it to us for some feedback. Basically, `@safe` was the default 
unless a function had no body. In that case, you had to have 
either `@safe`, `@system`, or `@trusted` on it or it wouldn't 
compile.

Jonathan asked if it was restricted to `extern(D)` functions. 
Átila said it wasn't. He said that `extern(D/C/C++)` only 
affected linkage and calling convention. People assumed that it 
meant the function was written in the respective language, but it 
didn't have to be. An `extern(C)` function could be a callback 
for C written in D, for example. If it was, then the compiler 
could verify if it was `@safe`. Linkage didn't enter into it. It 
was just a question of whether it had a body.

Dennis said that linkage kind of did come into it because `@safe` 
was mangled in the name of `extern(D)` functions to prevent you 
from linking to an `@system` function. Átila agreed but said 
that, just to make it simpler, if a function had no body it 
wouldn't compile without one of the three safety annotations.

Timon said that if you could add `@safe` to an `extern(C)` 
declaration with no body, then it would become ungreppable. Átila 
said he assumed they'd use `@trusted` in that case. But who knew 
what people would do? If they did use `@safe` there, it was on 
them because it was explicitly their declaration.

Timon said that the selling point of `@trusted` was that the 
language was defined such that when you got a memory safety 
issue, it was a compiler bug or an issue with something that was 
annotated as `@trusted`. If you allowed `@safe` on `extern(C)`...

Jonathan said that all we had to do was to disallow `@safe` on 
`extern(C)`. Timon agreed and said you could use `@trusted`. It 
had the same meaning in terms of the interface. The only 
difference between it and `@safe` was what it did to the function 
body.

Átila said that was a good point. That was the kind of thing that 
would come from feedback anyway.

Jonathan said that the fact that `@safe` and `@trusted` had 
different mangling was undesirable, though he didn't know if it 
was a big enough issue to change it. It didn't add any benefit, 
as it was the checking of the body that made the difference.

This led to a debate about whether it mattered if a function 
prototype was declared `@safe` or `@trusted`. A prototype was 
just an interface, and from that perspective, there was no 
difference. In both cases, the interface was safe.

Jonathan said that if he could suggest one thing, it would be to 
eliminate the mangling for `@safe` functions, then there would be 
no linking issues between `@safe` and `@trusted`. This mattered, 
for example, for delegates. If you used a delegate, you shouldn't 
have to care if it was `@safe` or `@trusted` because the 
interface was exactly the same, but you ended up having to care 
because of mangling.

Timon said what could be done was to allow `@trusted` function 
pointers and delegate types to decay to `@safe`. Walter said that 
sounded like a good idea on first blush.

Dennis brought up a compiler bug with mangling that existed 
because we had `@system` functions and default functions, which 
were `@system` by default. But if you called `getAttributes` on a 
function, whether you got `@system` or not depended on which one 
the compiler saw first, because `@system` functions were mangled 
with it and default functions were not.

Walter said that was a good point and was glad Dennis had brought 
it up, as he'd overlooked it. The entire type system relied on 
the concept that if they mangled the same, then they were the 
same.

Walter thought Timon's suggestion would help with Jonathan's 
issue. He suggested Jonathan try it out and see if it would work.

(Update: At the end of May, Átila posted threads in the DIP Ideas 
forum for [his Editions 
proposal](https://forum.dlang.org/thread/tskwospngntbnqiuxbag@forum.dlang.org) and [safe by default](https://forum.dlang.org/thread/uhmntnhqdwomdallfroo@forum.dlang.org).)

## Conclusion

At this point, the meeting was over, but we spent the next few 
minutes chatting about some interesting topics that came up 
through small talk as we were winding down. We held our next 
meeting on May 10.