On Wednesday, 31 July 2024 at 16:00:21 UTC, Jonathan M Davis
wrote:
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.
Unfortunately that leads to certain patterns that are safe using
dip1000 to now be @trusted. Which might cascade into surrounding
code needing to be trusted as well. Overall it's a loss.
I understand not everyone uses those patterns, which are mostly
focused on ownership and lifetime, but I have found them to
enable so called pit-of-success apis more than anything else.
Contrast that with more 'prescriptive' apis that for instance
require a certain ordering of calls or require certain functions
to be called at certain points, which are far easier to use
incorrectly. Plus they often fail/assert at runtime.
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
Don't forget the stack. Being able to safely use references to
the stack brings at least as much value.
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
The only two issues I have with dip1000 is that it a) sometimes
requires its attributes in seemingly unrelated code, and b) can
require some workarounds for its imperfect (practical?) tracking.
Overall though, I have found it is a natural conclusion when you
combine lexical lifetimes and references/borrows.
