D Language Foundation April 2024 Monthly Meeting Summary

[Jonathan M Davis]

On Wednesday, July 31, 2024 2:15:22 AM MDT Dukc via Digitalmars-d-announce 
wrote:
> Mike Parker kirjoitti 30.7.2024 klo 14.50:
> > 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.

DIP 1000 is attempting to make more stuff @safe than it is now -
particularly with regards to getting pointers to non-GC-allocated memory and
having the compiler verify that they don't escape. So, with DIP 1000, less
code has to be @trusted, but it's not at all necessary to have @safe code.

DIP 1000 is completely unnecessary if we take the stance that if you want
@safe, you use the GC, and any code that you have which can't do that for
some reason, you vet and mark as @trusted. The whole reason that DIP 1000
and @live and the like come into play is basically because Walter wants to
try to make dealing with malloc-ed memory @safe, but the cost in terms of
language complexity is enormous (and it doesn't really solve the problem
anyway, much as it does reduce it). So, DIP 1000 helps, but some of us think
that it's far too complex given what it costs, and it's definitely not
required to have a memory safe language. It's just that we need it (or
something which fulfills a similar role) in order to make more stuff @safe
(rather than @trusted) than we can currently do. Some stuff is going to need
to be vetted by programmers and marked with @trusted no matter what we do.

The problem with slicing static arrays does exist without DIP 1000, but that
can be solved by actually treating it as @system like it should be (since
it's basically just a different syntax for taking the address of a local
variable for a specific type of variable). Removing implicit slicing of
static arrays also improves the situation since then you don't get surprises
where you're doing something @system without realizing it. DIP 1000 is not
required to solve that problem.

Similarly, if there are any other cases where @safe code is not currently
guaranteed to be memory safe, it's either a bug in the implementation or in
the design. DIP 1000 is a way to add more to what can be automatically
treated as @safe. It's not a way to make a language that isn't memory safe
be memory safe. And it's primarily of value for folks who are actively
trying to avoid the GC.

- Jonathan M Davis