DMD 2.100, bring ont he attribute soup

[deadalnix]

On Monday, 30 May 2022 at 18:05:56 UTC, John Colvin wrote:
> Have you considered starting with some simple container 
> implementations and seeing how your design allows them to be 
> @live @safe? It would be good if the discussion had some 
> central & complete* examples that people can pick over. I feel 
> like all this discussion without concrete code that does real 
> work might easily lead to collective blind spots. Of course one 
> must make sure the theory makes sense to ensure generality, but 
> concrete examples are excellent checks.
>
> * i.e. would actually be useful. Even an example showing how to 
> implement a @live @safe array type would be enlightening. The 
> best would be "this complete, useful library type sucks in D, 
> here's how it would be much better with @safe @live D".
>
> Forgive me if these already exist somewhere.

I'm not sure a container exist, but there are various code 
samples in bug reports and in discussion in this forum. This 
debate has been going on for literally a decade, and I guess 
there are only so many time people will go through the effort of 
coming up with a realistic piece of code to make a point.

In any case, it seems to me that we are suffering from the exact 
opposite problems. As far as I can tell, D is rolling out 
solution to specific problems after solution to specific 
problems, which balloons the complexity while never getting at 
the root of the problem.

Consider that type qualifier, DIP1000, @live, @nogc, RCObject, 
and probably a few more, are all variations around the theme of 
ownership. But because we look at it from a specific angle, and 
attack that angle, we just accumulate partial, but incomplete 
solutions.

When looking at it this way, the #1 problem D faces becomes 
invisible. yes, DIP1000 is simpler than ownership. Yes, @nogc is 
also simpler than ownership. Maybe - not sure - @live is simpler 
than ownership. RCObject is also definitively simpler than 
ownership. Type qualifier are also simpler than ownership.

But you know what is not simpler than ownership? Type qualifers + 
DIP1000 + @nogc + @live + RCObject. And yet, the power you get 
from them is also significantly less than full blown ownership.

There is a case to be made that we do not want ownership in D, 
because it is too complex, because Rust captured that market, or 
whatever. But then we got to embrace the GC, optimize allocations 
via escape analysis, and so on (a study of optimizations done for 
Java or JS would be a good primer to know what the options are 
here). Or we decide that we do want it.

What doesn't make sense is pretend we don't want it, and 
implement broken version of it after broken version of it. This 
only becomes apparent when you stop looking at individual 
examples, step back, and look at the emerging patterns.