D Language Foundation April 2024 Monthly Meeting Summary

[Dukc]

Mike Parker kirjoitti 30.7.2024 klo 14.50:
> The D Language Foundation's monthly meeting for April 2024 was held on 
> Friday the 12th. It lasted an hour and 20 minutes.
> 

Wow, this has a lot to comment on!


> 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.

Unfortunately, this is likely only the tip of an iceberg. I don't think 
many people currently use `@live` since it has so few use cases. Hence 
bugs likely remain under the surface.

> 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.

There's a much better study case for this than Managed C++. Namely, Nim, 
probably the closest competitor of D. It also has different types for 
GC-managed and manually allocated pointers, unless my memory completely 
betrays me.

> 
> 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.

I though it was vice-versa - the language is unsafe *without* dip1000. 
Or does Timon mean implementation bugs in it?

But I do agree that it's best to program mostly like DIP1000 didn't 
exists and just rely on the GC. DIP1000 is there to catch the case where 
you accidentally return a self-pointer from a member function or a slice 
of your static array on stack.


> 
> 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.

Don't you remember? Timon [has already 
shown](https://forum.dlang.org/post/tr9j1h$1fvd$1@digitalmars.com) it 
can be done.

> 
> 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.

To see why, try to write an userspace function that manually mallocates 
and frees. You can write only general-purpose `@trusted` and `@system` 
functions - meaning, something that could potentially get accepted to 
Phobos. All code tailored to the use case of the user needs to be 100% 
`@safe`. You may freely use or not use `@live` on any function as you 
see fit.

If I'm on the map here, this can only be accomplished with Timon's trick 
I linked to, and it doesn't use `@live` at all. `@live` doesn't provide 
any additional means to do this.

> 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...

This is an important point, but I have a slightly different take. Any 
way these issues are going to be fixed (if they are to be) must stay out 
of the way of those who don't care. That is, if you happily let GC to do 
memory management for you, or are happy to manually review your 
mallocations and frees accepting the risks, your life must not get any 
more complicated.

But if you want to have it all - both memory safety and no gc - that's a 
complex problem by definition. You can't expect to do that without a 
significant learning curve for your tool.

> 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.

Please don't. What's wrong with keeping DIP1000 optional until we have 
editions, and making it the default in the next edition? That way no-one 
has to migrate if they can't.


> 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.

I also suggest this. Not because Robert's way would be worse than 
DIP1000 tricks, but because DIP1000 is a strict superset of Roberts 
proposal. You can totally keep DIP1000 as it exists enabled and program 
with no `scope` or `return` usage.

> Á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.

That's the case with pretty much anything. If I leave some work aside 
for a few years, install newer versions of the compilers and libraries I 
was using and then open up my work again, it's pretty likely I will have 
to open the docs and see how I'll migrate my work, regardless of the 
language/libraries. If the docs say "just add edition declaration to top 
of your file, or use a compiler switch", I'm actually lucky. It isn't 
realistic to expect better from any language or library that is still 
being developed.


> 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.

Maybe related to https://issues.dlang.org/show_bug.cgi?id=24003 ?