D Language Foundation April 2024 Monthly Meeting Summary

[Sebastiaan Koppe]

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.