D is dead

[Walter Bright]

On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
> On 23/08/18 09:58, Joakim wrote:
>> Because you've not listed any here, which makes you no better than some noob
> 
> Here's one: the forum does not respond well to criticism.

Not sure what you mean by that.


> * Features not playing well together.
> 
> Despite what Joakim seems to think, I've actually brought up an example in this 
> thread. Here is another one:
> 
> 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?


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

This is in the language spec:

https://dlang.org/spec/statement.html#foreach-with-ranges

"If the aggregate expression is a struct or class object, but the opApply for 
foreach, or opApplyReverse foreach_reverse do not exist, then iteration over 
struct and class objects can be done with range primitives."

This was done for backward compatibility, since empty/front/popFront came later. 
I actually tried to deprecate opApply at one point, but that would have broken 
too much existing code. But I'm puzzled why one would write a struct with both 
iteration mechanisms.


> Does it matter if it allows copying or not?

For the preference for opApply, no.


> The language was built because C++ was deemed too complex! Please see the thread 
> about lazy [1] for a case where a question actually has an answer, but nobody 
> seems to know it (and the person who does know it is hard pressed to explain the 
> nuance that triggers this).

C++ doesn't have lazy. Lazy in D is a rarely used feature, so I'm not surprised 
there is less institutional knowledge about it, and it hasn't been thrashed as 
much as other features.


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


> * The community
> 
> Oh boy.
> 
> Someone who carries weight needs to step in when the forum is trying to squash 
> down on criticism. For Mecca, I'm able to do that [2], but for D, this simply 
> doesn't happen.

If someone is trying to squash criticism, I would like to see what you're 
referring to. If a post contains unprofessional behavior, like using f--k or 
harassing people, it will get removed. Simply being critical is not removed (if 
it was, this this thread would have disappeared).