DMD 2.100, bring ont he attribute soup

[Dukc]

On Thursday, 26 May 2022 at 14:35:57 UTC, deadalnix wrote:
> This is the opposite of progress. Stop it.
>
> I'd be happy to add attributes for something that could 
> actually track ownership/lifetime. DIP1000 is not that. Adding 
> attributes for that is not worth it.

Despite quoting Amaury, my reply is aimed at everyone here.

DIP1000 is sure a difficult concept to learn, and I agree it's 
onerous to migrate code to use it and it does not discover that 
much flaws in existing code. But there is one imperative point 
that I haven't seen mentioned here.

There was a fundamental design flaw in `@safe`, and DIP1000 is 
the solution to it. It's not just about enabling new paradigms, 
it's about plugging a hole in existing one. These compile without 
the DIP, but are detected by DIP1000:

```D
@safe ref int oops1()
{ int[5] arr;
   int[] slice = arr[];
   return slice[2];
}

@safe ref int oops2()
{ struct AnInt
   { int here;
     int* myAddress()
     { auto result = &here;
       return result;
     }
   }

   AnInt myInt;
   return *myInt.myAddress;
}
```

If you're against DIP1000, you have to either:

- Say that we should resign the purpose of `@safe` eliminating 
undefined behaviour from the program. I'd hate that.

- Say that we should simply disallow slicing static arrays and 
referencing to address of a struct member from a member function 
in `@safe` code. That would break a LOT of code, and would force 
`@safe` code to resign quite a deal of performance. I'd hate that.

- Come up with a better idea for escape checking. For one, I 
cannot.


One thing I want to mention is that you only need `scope` if 
you're going to work with data in the stack. Often it's more 
pragmatic to just allocate stuff on the heap so you don't have to 
fight with `scope` checks.

DIP1000 is currently only scarcely documented. I'm considering 
doing a series of blog posts to the D blog about DIP1000, that 
would probably help.