Why is D unpopular, redux. (page 14)

On 25.05.22 02:23, Walter Bright wrote: > On 5/24/2022 4:47 PM, Timon Gehr wrote: >> The issue is: sometimes there are pull requests that _don't actually fix the issue they purport to fix_. Why should that cause a changelog entry that claims the bug was fixed? > > If the supplied example works correctly, the bug is closed. > ... That encourages pseudo-fixes that focus on special cases. > Is it really too much to ask for: > > 1. people to submit bug reports to bugzilla, not the n.g.? > ... I do submit bug reports to bugzilla. > 2. provide an example of the bug? > ... Well, sometimes the person who finds the bug is not great at making examples, then others provide better ones on the same bug report. > Making me debug the provided example and/or guess what the submitter actually intended is too much to ask. (Often the subject line is completely wrong, too, and I often fix them.) > > I've been cutting and pasting your n.g. bug reports to bugzilla. This really does not scale. All of the bug reports were already in bugzilla, though maybe my examples on the NG made the issues easier to understand. I can get more proactive in filing enhancement requests again.

May 24, 2022

Re: Why is D unpopular, redux.

Posted by Walter Bright
in reply to deadalnix

Permalink

Walter Bright

Posted in reply to deadalnix

Permalink

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

On 5/24/2022 5:03 PM, Timon Gehr wrote: > In this instance the problem seems to be that you are biased towards accepting immediately that stuff is actually not broken without examining closely enough what is going on. I do what I can, but I expect things from users too: ** A bug report with a minimized example that illustrates the bug ** If the example does not illustrate a problem, then I move on to the next bug report. I've spent much time in the past trying to guess what the user meant, and usually guess wrong, which wastes everyone's time. I can't get to all of them, so I prioritize the bugs where the submitter made an effort to make it easier for me to deal with it.

On 5/24/2022 4:35 PM, Timon Gehr wrote: > This compiles even with -dip1000: > > ```d > import std.stdio; > > void main()@safe{ > void delegate()@safe[] dgList; > foreach(i; [1, 2, 3]) { > immutable b = i; > dgList ~= { writeln(b); }; > } > foreach(dg; dgList) dg(); > } > ``` > > I.e., this issue is alive and well. It's a memory safety issue in @system code and it's a soundness problem for @safe. https://issues.dlang.org/show_bug.cgi?id=23136

On 25/05/2022 1:05 PM, Walter Bright wrote: > ** A bug report with a minimized example that illustrates the bug ** dustmite <3 I ran into a bug related to extern(C++) classes in -betterC, already reported, did the minify. Looks like the fix didn't make it into 2.100 sadly. https://issues.dlang.org/show_bug.cgi?id=21416 I just want to say that the process certainly works when people like Razvan are around and able to fix these issues, rather than having to debate or argue about if it should be fixed or not. It is appreciated!

On Tuesday, 24 May 2022 at 23:48:06 UTC, deadalnix wrote:

Well, the thing is, D is good at many thing, but it's not great at one thing. You therefore don't get that 1% of dev who really want or even need it.

Yes, and since growth where there is a networking effect might follow the exponential-like S shape (sigmoid) we can also expect that libraries/frameworks happen when we enter the steep slope of the S curve. That one Rust feature is acting like a catalyst, you get higher density of a particular user type. Same with Go, since it was Google the initial influx was people with an interest in web or cloud, so that would be how it entered the S shape, the libraries/framework follow from that density of user types and boosted the already existing networking effect.

We dont really see a networking effect in D.

We dont see a condensation of a particular user type, except metaprogramming and language evolution, and that has boosted demands that doesn’t increase a particular niche fitness.

These action taken effectively prevent the ecosystem from growing. Just like bonsai, it get trimmed on a regular basis, so it stays small.

Yes, it has to fix all the individual causes that prevents retention, then communicate a clear specific vision that fits a niche that is poorly covered. Could be gui apps on Linux or something else, but something specific is easier to target and measure than something abstract.

By being more specific you also can grow the ecosystem somewhat faster because the key demands are more focused.

On Tuesday, 24 May 2022 at 15:31:47 UTC, Adam D Ruppe wrote: > > Use the `let` keyword for a local lexically scope thing, and then you'll see the cb behavior is different. > > Since D's scoping is more like `let` than `var`, JS is a point in favor of it being a bug. > Also you should never use var anymore anyway, always use let if you can, which you can in 99.9% of all cases since it really only isn't supported with older engines. In fact I'd argue that the only reason var isn't a deprecation in JS is because of legacy code.

Forums