DMD 2.100, bring ont he attribute soup

[H. S. Teoh]

On Mon, May 30, 2022 at 08:26:46PM +0000, deadalnix via Digitalmars-d wrote:
[...]
> 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.

Totally agree with this!


> 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.

Yep.  Lately I've been feeling like we're missing the forest for the
trees.  We're tackling every individual tree with heroic effort, but
we've lost sight of the forest and where we want to be heading. (Or
maybe we just can't come to an agreement of where we want to be heading,
so we decide to tackle the entire forest, one tree at a time.) We're
just inventing one ingenious engineering solution after another to deal
with the tree immediately in front of us, accumulating technical debt,
yet we have no idea what the next tree behind this one will be, let
alone the rest of the forest.  In the end, we accumulate lots of
powerful tools for cutting down individual trees but none that can take
us through the forest, because we don't even know which direction we're
supposed to be heading. We're just hoping and wishing that after
tackling N trees ahead of us we will somehow magically make it to the
end -- but what that end is, we don't have a clue.


> 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.

Exactly. We tackle individual trees marvelously, each with its own
specialized tool. But put all those tools together, and we still can't
take on the forest.


> 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.

IOW, decide which edge of the forest we want to end up on in the first
place, before we engage our engineering genius to tackle individual
trees! :-D


> 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.

I wouldn't say it's broken, each tool we invent works marvelously well
against the tree directly ahead of us.  The problem is that we don't
know which trees we should be tackling, and which side of the forest we
want to end up in at the end.  We heroically deal with the tree of type
qualifiers, then discover standing behind it tree of escaping references
1-level deep. We fell that with great aplomb, then we discover facing us
the tree of escaping reference 2-levels deep.  We deal with that with
equal engineering genius, but behind it stands another tree, requiring
yet another heroic engineering effort to deal with.  With every tree we
accumulate more technical debt, but we haven't even figured out whether
all of them combined will get us "there" -- because we haven't even
figured out where "there" is. :-/


T

-- 
Why ask rhetorical questions? -- JC