Why is D unpopular, redux.

[Timon Gehr]

On 22.05.22 03:26, Walter Bright wrote:
> 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.
> ...

Instances of the same struct/class template are independent types 
without any relationship. Different types of slices (for example) are not.

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

The bug report is 15 years old:

https://issues.dlang.org/show_bug.cgi?id=1983

Example:

```d
class C{
     int x;
     void delegate() dg;
     this(){
         dg = (){ x++; }; // mutate x
     }
}

void main(){
     const c=new C();
     auto old_x=c.x;
     c.dg(); // accepts invalid
     auto new_x=c.x;
     assert(old_x==new_x);
}
```

Solution: Properly type check the context pointer, for example it should 
not be possible to call a `const(void delegate())` dg because the 
context is const, but the function pointer accepts a mutable context.

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

Another 15 year old bug report:

https://issues.dlang.org/show_bug.cgi?id=2043

Example:

```d
void main(){
     int delegate()[] dgs;
     foreach(i;0..2){
         immutable int k=i;
         dgs~=()=>k;
     }
     assert(dgs[0]()==0&&dgs[1]()==1); // fails
}
```

Solution: If a delegate closes over a loop-local variable, create one 
context per loop iteration. (The `immutable` in the example above just 
demonstrates that what's going on is memory corruption, it should still 
work the same way if there is no `immutable`.)

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

There is no way to declare a tail-immutable class reference.

immutable(int)* <- can rebind the reference, can't assign to value

immutable(Class) <- can't rebind the reference
Class <- can rebind the reference, can assign to value

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

Maybe we can bump the priority on the bugzilla issues?