D is dead

[Shachar Shemesh]

On 23/08/18 14:02, Walter Bright wrote:
> On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
>> functions may be @safe, nothrow, @nogc, pure. If it's a method it 
>> might also be const/inout/immutable, static. The number of libraries 
>> that support all combinations is exactly zero (e.g. - when passing a 
>> delegate in).
> 
> If, for example, a library functions allocates with the gc, then it 
> can't work with @nogc code. But still, fair enough - if there are 
> combinations which should work, but do not, please submit bug reports. 
> If you have already, is there a list of them?

None of that continues to work once delegates are involved. I am yet to 
see a library that can accept a delegate and correctly create a function 
around it that matches its attributes.

And yes, I do include Mecca in this. I tried. It is too difficult to get 
right, so I gave up.

Attribute inference was supposed to solve this, but attribute inference 
is completely broken with separate compilation.

> 
> 
>> * Language complexity
>>
>> Raise your hand if you know how a class with both opApply and the 
>> get/next/end functions behaves when you pass it to foreach.
>  > How about a struct?
> 
> I presume you meant empty/front/popFront.
Indeed.

> 
> This is in the language spec:

How many people know that without resorting to the specs.
> 
>> Does it matter if it allows copying or not?
> 
> For the preference for opApply, no.

But it does for empty/front/popFront, which is exactly my point.

> 
>> * Critical bugs aren't being solved
>>
>> People keep advertising D as supporting RAII. I'm sorry, but "supports 
>> RAII" means "destructors are always run when the object is destroyed". 
>> If the community (and in this case, this includes Walter) sees a bug 
>> where that doesn't happen as not really a bug, then there is a deep 
>> problem, at least, over-promising. Just say you don't support RAII and 
>> destructors are unreliable and live with the consequences.
> 
> If you're referring to #14246, I posted a PR for it. I don't see how 
> that is pretending it isn't a problem. It is.

When I first reported this, about 3 and a half years ago, the forum 
explained to me that this is working as expected.

#14246 was over 2 years old by the time you posted the PR. Once posted, 
however, it broke (I'm not sure why it broke, but did notice it 
deliberately would not work with @disable init structs. See my 
interoperability comment from above). Since then (over a year), no 
progress has been made except to revert the changelog that claims it was 
resolved.

When I talked to you about it at the last DConf, I got a reply that 
could be largely summarized as "yeah, we should probably do some flow 
analysis, sometimes".

The only time I got anyone to take this problem seriously was when 
someone on the forum would claim that D supports RAII, to which I tend 
to reply with "no, it doesn't".

So you will excuse me, but I don't think this bug is being taken as 
seriously as I think it should.

I get it, it is not a simple bug to solve. It is an unfortunate truth 
that some important bugs are not going to be easy. C++ went a different 
path with this (strictly setting when members are initialized). I get 
that this is a very unpopular feature of C++, and I can see why, but 
seeing how D struggles to resolve this issue, I can't say it is a 
mistake on C++'s behalf.

Shachar