Editions Ideas

[Jonathan M Davis]

On Sunday, December 14, 2025 1:23:51 PM Mountain Standard Time Walter Bright via Digitalmars-d wrote:
> On 12/14/2025 3:44 AM, Paul Backus wrote:
> > We can (and should) improve memory safety by closing holes in @safe. For
> > example, instead of using -preview=dip1000 we can simply forbid @safe code from
> > taking the address of a stack-allocated variable (passing by `ref` is fine though).
>
> Then you cannot have arrays on the stack, which are a highly useful construct (I
> use them all the time).

There's an enormous difference between not being able to do something and
not being able to do something in @safe code.

You can have arrays on the stack just fine. It's just that slicing them has
to be @trusted, because you have to ensure that the resulting dynamic array
doesn't outlive the static array, and the compiler can't do that without
some sort of lifetime tracking. The fact that slicing a static array is not
currently treated as @system is a hole in @safe, and it should have been
fixed by making it an error years ago, but instead, you decided to put that
off in favor of fixing it with DIP 1000. So, we've had this hole in @safe
for years when what we should have done is close the hole. We can improve
the language later if we can come up with a way to track escaping references
in a sane manner, but IMHO, that's no reason to leave a hole in @safe while
we don't have that solution.

There really isn't a difference between using & on a variable and using []
on a static array except that you get the length along with the pointer, and
they should be treated the same.

The first edition is a prime time to close all of the known holes in @safe,
which includes anything involving static arrays - be it explicit or with
features like typesafe variadic arrays which are actually implemented as
slices of static arrays. IMHO, putting off fixing holes in @safe just
because we don't want to "break" someone's code makes @safe borderline
meaningless. We need to close the holes. With Editions, we can choose to do
that by restricting such changes to new Editions rather than fixing them as
soon as we find them, but we need to stop leavin these holes open.

That does not preclude improving the language later and making @safe apply
to more as we're able to do so, but we should not leave holes in @safe just
because we don't like the fact that we can't currently guarantee that
something is memory safe.

- Jonathan M Davis