DMD 2.100, bring ont he attribute soup

[Walter Bright]

On 5/26/2022 3:54 PM, deadalnix wrote:
> To begin with, I don't expect the same level of analysis from a static analyzer 
> than from the compiler. I can ignore the static analyzer if it is wrong, I 
> cannot ignore the compiler, after all, I need it to compile my code. False 
> positive are therefore much more acceptable from the tool than the compiler.

The static analyzer should be built in to the language when looking for bugs, 
not stylistic issues.


> Second, I expect the constraint checked by the compiler to provide me with 
> useful invariant I can rely upon. For instance, if some data is immutable, and 
> that it is really an invariant in the program, then I can know this data can be 
> shared safely as nobody else is going to modify it.  The existence of the 
> invariant limits my options on one axis - I cannot mutate this data - while 
> opening my option in another axis - i can share this data safely without 
> synchronization.
> 
> If immutable instead meant immutable in most places, you you can mutate it with 
> this weird construct, then it is effectively useless as a language construct, 
> because it restrict my expressiveness on one axis without granting me greater 
> expressiveness on another.

Immutable means immutable in D, all the way. I've fended off many attempts to 
turn it into "logical const" and add "mutable" overrides. Most of the complaints 
about immutable and const in D is they are relentless and brutal, not that they 
don't work.

Yes, we find holes in it now and then, and we plug them.


> Breaking the invariant must be breaking the type system, which is only possible 
> in @system code and comes with all the appropriate warnings.
> 
> The problem with DIP1000, is that it doesn't provide me with invariant I can 
> rely upon,

It does for stack based allocation.


> because it is unable to track more than one level indirection. It can 
> only detect some violation of the invariant, but not all (in fact, probably not 
> the majority).

It's designed to track all attempts to escape pointers to the stack, and I mean 
all as in 100%. It will not allow building multilevel data structures on the 
stack. Yes, some implementation bugs have appeared and a lot has been fixed 
(with Dennis' help). Some mistakes in the design have been discovered and 
adjustments made.

So far (fingers crossed) no *fundamental* problems with it have been found.


> As a result, it doesn't allow me to build upon it to make 
> something greater.

@live builds upon it and relies on it. I agree @live has yet to prove itself, 
but focus is on ImportC and dip1000 for the moment.