Why is D unpopular, redux.

[Walter Bright]

On 5/21/2022 5:14 PM, deadalnix wrote:
> On Saturday, 21 May 2022 at 19:46:48 UTC, Walter Bright wrote:
>> On 5/21/2022 4:54 AM, deadalnix wrote:
>>> There are holes in the foundations of the languages. These hole prevent basic 
>>> things from being possible at all. For instance, containers.
>>
>>
>> Ok, can you please provide a comprehensive list of these holes?
> 
> I've done so a gazilion time, and the fact you cannot think of one is the focus 
> problem I'm talking about.

The trouble is, posting these on the n.g. is not a good method, as the n.g. is 
ephemeral and no, I don't read every posting. Nobody can. When someone says "it 
was posted on the n.g. some time ago" there's just no way to deal with that. The 
n.g. is like 15 years worth of receipts thrown down the stairs into the basement 
to be forgotten.

A better way is to think them through, and post enhancement requests on 
Bugzilla. That's what it's for. Then, when someone says "what about XXX that I 
proposed" he can point to the bugzilla issue. If anyone has anything substantive 
to say about it he can attach comments to that issue.

A more formal way is to create DIPs for them.


> Just on type qualifiers:
>   - Transitivity of type qualifier doesn't play nice with template. There is no 
> way to tell the compiler that a `const Tpl!T` actually is a `const Tpl!(const 
> T)`. As a result, no container library is possible and ranges have serious 
> problem when it come to qualifiers too.

This needs a lot more fleshing out about what exactly is wrong and why.

>   - delegates break constness guarantees as the type qualifier ont he context is 
> not tracked and/or checked.

This should be a bug report in bugzilla with an example.

>   - closure break constness guarantee, as I can mutate an immutable variable 
> visible in a closure when iterating in a loop.

This should be a bug report in bugzilla with an example.

>   - There is no way to build a shared object without breaking the type system.

That's correct. It's intended to be done with @system code. I don't know any way 
out of that, if you know of one, please make an enhancement request. (You can't 
write a storage allocator in @safe code, either.)

>   - shared is supposed to be explicit, yet all objects have a monitor - granted 
> this one is not broken per se, but a major WTF.

The monitor idea turned out to be a bad idea. I recommend simply ignoring it.

>   - synchronized shared object cannot provide the guarantee they are supposed to 
> because there is no adequate escape analysis.

I don't know what this means.

>   - const/immutable doesn't play nice with reference types (the qualify both the 
> object and the reference), making the type qualifier system pretty much 
> unworkable with OOP style code.

This needs to be a lot more specific. "doesn't play nice" is just not helpful.

> Now, don't get me wrong, some of these are hard problems. But the more we add to 
> the pile of stuff we have, the harder they become to solve.

Thank you for writing the list.