DMD 2.100, bring ont he attribute soup

[Walter Bright]

On 5/26/2022 7:35 AM, deadalnix wrote:
> So I upgraded to 2.100
> 
> It is now reporting DIP100 deprecation by default.
> 
> Fantastic. Every single one of them is a false positive so far. I now face the 
> situation where I will have deprecation warning forever, or add attribute soup 
> to the program.
> 
> 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.

Many others report the same experience.

Not so long ago, I was asked to try out one of the popular C++ code static 
analyzers. Since at the time the D backend was still written in C++, I thought 
"great! let's see if it finds any bugs in the backend!".

It found zero bugs and 1000 false positives.

Does that make it a useless tool? Not at all. The thing is, the backend is 35 
year old code. All the bugs had already been squeezed out of it! The false 
positives were things like printf formats (like printing a pointer as a %x 
instead of %p), pointer aliasing issues (modern code should use unions instead 
of casts), irrelevant portability issues, etc.

The same issue came up when const was added to D. It didn't fix existing, 
working, debugged code, either.

It's come up as well when C and C++ tightened their language specs.

The additional semantic checking is for:

1. new code - so you don't have to debug it, the compiler tells you right off 
the bat

2. self-documentation - so you know what a function plans to do with a pointer 
passed to it

3. when a pointer is marked `scope`, you don't have to double check it. The 
compiler checks it for you.

After all, you pointed out where D allows implicit conversion of a mutable 
delegate to an immutable one. The fix is:

     https://github.com/dlang/dmd/pull/14164

but it breaks existing, working, debugged code. What do you suggest we do about 
that? Remove immutable annotations? Ignore immutable annotations? Or fix user 
code to be const-correct? (I made it opt-in by putting it behind the dip1000 
switch. It will eventually become the default.)

As for lifetimes, yes, I know that dip1000 only addresses one level of 
lifetimes. The fix for all levels is the @live stuff, which has already been 
merged. But we've decided on fixing all the dip1000 issues before putting a 
major effort into @live. The @live implementation depends on dip1000, and you'll 
be pleased to note that it only is turned on a function-by-function bases iff 
that function is marked @live. It's completely opt-in.

BTW, if you use templates, the compiler will infer the correct dip1000 
attributes for you.