D not considered memory safe

[Dukc]

Walter Bright kirjoitti 28.7.2024 klo 21.12:
> On 7/26/2024 10:11 AM, Dukc wrote:
>> What I fail to see is why would marking the *called* function 
>> `@trusted`, when it's API is actually unsafe, be any better than the 
>> lambda trick? All the issues that make the lambda trick bad still 
>> apply, only worse.
> 
> I've answered that question probably a dozen times here.

Right, you wrote that `@trusted` serves as your greppable todo list (as 
opposed to a comment or UDA most of us would use for that purpose). I 
quess `@trusted` lambdas wouldn't do (nor marking the calling function 
`@trusted`) as the permanent solution if that's the case.

This can actually work in in one particular case: If you're going to 
make the module in question 100% `@safe`. This means no pointer 
arithmetic, no manually freeing memory, no typecasting. You're known for 
your willingness to use unconventional low level tricks to speed up the 
compiler. Are you really ready to get rid of everything that isn't 
allowed in `@safe`, or failing that, to push such code to another module 
where there will be no temporary safewashing?

If you are, you can actually demonstrate it! Given you've accepted the 
need to make everything in `dmd/backend/dlist.d` `@safe` in the long 
term, there is at least one long-term solution for `list_delete(list_t)` 
that you would accept. What would that be?