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
