Why is D unpopular, redux.

[Walter Bright]

On 5/24/2022 5:08 PM, deadalnix wrote:
> But they are not, and this is why this doesn't get resolve. These aren't bugs, 
> there is a design issue.

You've suggested I resolved the const conversion problem with some special case 
code. I did not. The other problem you said was the same is on a completely 
different path through the compiler. This needs to be a separate bug report.

I do try to resolve problems with a general solution. I never ever submit PRs of 
the form:

     if (identifier == "a" && operator == "++") then insert hack.


> You have essentially two way to go at it:
> 1/ Allocate a closure int he loop. This remains unsound by itself because the 
> qualifier of the closure is not tracked, which lead to possible implicit sharing 
> for instance and other nastyness. There is not enough information in the 
> typesystem to solve this, so going at it bug by bug will simply be an exercise 
> in wack a mole.
> 2/ Prevent capture of object beyond their lifetime. This require ownership and 
> lifetime tracking. DIP1000 doesn't have the depth required to do so adequately - 
> it lacks the recursiveness required to track indirections - so once again, 
> fixing bugs one by one is an exercice in wack-a-mole.
> 
> Because the design is inadequate to begin with, you can only fix presumably more 
> common holes (because they got reported first) by creating more uncommon ones at 
> best, make no progress at worse.
> 
> To fix these problems, you actually need to think of the system it term of the 
> invariant that each part either require or imply, and find where these do not 
> match.

I'm sorry you've concluded I never think about these things. I am very well 
aware that dip1000 only looks one level. That's why I *also* implemented an 
ownership/borrowing system with @live. I know Timon does not like that proposal, 
but that's another discussion entirely.

I have never introduced a PR to hack in a two-level indirection bug fix.


> these problem with closure are quite complex, but there is an exemple of this 
> that is much simpler and easy to grok: final switch vs non promoting binary 
> operation on enums.
> 
> One assumes the invariant that enum are bounded to the set of values declared in 
> the enum, but the second doesn't effectively relegating the enums to be a 
> subtype of their base class. They just cannot be both within a sound system.
> 
> There is no amount of getting test cases to pass that will fix this problem with 
> enums, because it is a design problems. Almost all soundness problems are, BTW.

You might be surprised to learn that I know that enums have no checks in them to 
ensure an instance of an enum has only values matching the list of enum values. 
I haven't regarded it as terribly important because:

1. enums are often combined as bit flags
2. it's not a memory safety issue
3. it's the way C and C++ work and there is a user expectation for that behavior