DIP1000 observation

[Jonathan M Davis]

On Sunday, August 25, 2024 11:55:04 AM MDT Bruce Carneal via Digitalmars-d 
wrote:
> The lesson I take from the DIP 1000 history is that we need
> something that is simpler to explain, something that is much
> easier to use correctly, something that models the problem more
> clearly.
>
> Bug reporting/fixing is great, but sometimes the bug pattern
> indicates a rethink is in order.  I believe this is one of those
> times.

I am strongly of the opinion that DIP 1000 is far more complex than it's
worth and that we'd be better off just dropping it. If you're primarily
using the GC, then DIP 1000 doesn't even help you, because it's focused on
stuff like trying to make taking the address of a local variable @safe
instead of just leaving that up to the programmer like we always have. D can
already be memory-safe quite easily so long as you minimize stuff like
taking the address of local variables, and we have @trusted to deal with
those issues. The GC allows us to treat the vast majority of stuff as @safe,
and @trusted lets us deal with the rest.

The main problem with the current situation IMHO is that slicing static
arrays is not treated the same as taking the address of a local variable
even though it's exactly the same thing except that the length of the array
is passed along with the address. If we treat that as @system (and
preferably also remove the implicit slicing of static arrays), then the main
@safety hole that we currently have that I'm aware of is plugged. And if we
have additional @safety holes, we can address each of those individually by
treating stuff that's @system as @system instead of complicating the
language further to try to treat more as @safe without needing @trusted.

The problem of course is then the folks who want to be able to do stuff like
take the address of a local variable and have the compiler be smart enough
to determine that that's @safe - particularly since if they're doing it
correctly, it will be. However, I _really_ don't think that the complexity
that comes with DIP 1000 is worth fixing that problem. Unless a D program is
actively trying to not use the GC, only a small portion of the program is
going to be doing stuff like taking the address of a local, and normally,
taking the address of a local is restricted enough with what it's doing
(since it pretty much has to be if you don't want the address to escape)
that it shouldn't be hard to manually verify that no escaping is taking
place. And if it is hard to verify manually, the odds are that you're going
to have to cast away scope to shut up the compiler with DIP 1000 anyway,
because the compiler won't have been able to verify it either.

If someone is able to come up with an alternate solution which is much
simpler, then great! It would be awesome to be able to treat more stuff as
@safe without needing @trusted. But as Walter has pointed out, a lot of the
complexity that comes with DIP 1000 is because D is a complex language, and
I'm not convinced that it's even possible to come up with a simple solution
to this problem unless we do something like get rid of separate compilation
so that the compiler can examine all of the code and track the lifetimes of
everything (which we're obviously not going to do, since that has a very
large cost in other areas like compilation times and integrating with C/++
code).

D is already able to make a lot of code memory-safe thanks to the fact that
it has a GC, and I think that we should stop digging this rabbit hole that's
trying to make malloc and taking the address of locals memory-safe without
requiring @trusted. It's just not worth it.

Personally, every time that I've even tried to use DIP 1000, I've given up,
because it's just too much of a pain. And honestly, I suspect that if DIP
1000 ever gets made the default, I will either just be casting away scope
everywhere that the compiler infers it and slap @trusted on that code to
shut the compiler up, or I'll just give up on making that code @safe. I'm
perfectly fine with manually verifying the rare case where I need to take
the address of a local variable or slice a static array, and I do _not_ want
to deal with figuring out where and how I need to slap scope everywhere to
make the compiler happy - especially when it's then going to start
complaining about stuff that worked perfectly fine and was quite memory safe
prior to scope getting involved.

- Jonathan M Davis