D is dead

[Walter Bright]

On 8/23/2018 5:55 AM, Steven Schveighoffer wrote:
>> If front() returns by ref, then no copying happens. If front() returns by 
>> value, then a copy is made. This should not be surprising behavior.
> I think he means, if the range ITSELF doesn't allow copying, it won't work with 
> foreach (because foreach makes a copy), but it will work with opApply.

     foreach (ref v; collection)

does not make a copy. It's up to the programmer whether copying is done with it. 
After all, if one is passing a struct instance around by value instead of by 
ref, there is no escaping copying it. This should not be surprising.

Designing a non-copyable struct is a more advanced technique, and it is 
reasonable to expect that someone using it should understand the consequences.


> There are many people who post short curt answers, maybe even cynical. But this 
> isn't necessarily the authoritative answer. Where I see this happening, I 
> usually try to respond with a more correct answer (even though my voice isn't 
> authoratative exactly), but the sad truth is that we can't spend all our day 
> making sure we have a super-pleasant forum where every answer is valid and 
> nobody is rude.

The D forums are deliberately set up to allow people the freedom to say what 
they wish as much as possible, we only put minimal restrictions on it, such as 
we expect professional demeanor.

What we aren't going to do is vet every post for consisting only of approved 
opinions. That wouldn't even be a forum - it would be an echo chamber.


> In reply to Shachar's general point:
> This whole thread seems very gloomy and final, but I feel like the tone does not 
> match in my mind how D is progressing. "Every single one of the people [at Weka] 
> rushing to defend D at the time has since come around." Seems like you all have 
> decided to either ditch D internally, maybe moving forward, or accepted that 
> Weka will fail eventually due to the choice of D? It sure reads that way.
> 
> This is in SHARP contrast to the presentation that Liran gave at Dconf this 
> year, touting D as a major reason Weka was able to develop what they did, and to 
> some degree, your showcase of how Mecca works.
> 
> My experience with D is that it has gotten much better over the years. I suppose 
> that having worked with the earlier versions, and seeing what has happened gives 
> me a different perspective. I guess I just don't have that feeling that there 
> are some unfixable problems that will "kill" the language. Everything in a 
> programming language is fixable, it just matters how much pain you are willing 
> to deal with to fix it. If we get to a point where there really is a sticking 
> point, D3 can be born.
> 
> I do feel that we need, in general, more developers working on the compiler 
> itself. So many of the problems need compiler changes, and the learning curve to 
> me just seems so high to get into it.

I've been programming for 40 years. Every language, and every implementation, 
has had problems, often requiring significant effort to deal with them. The 
issue for me is, can I get my work done?

For example, @safe isn't 100%. But simply having buffer overflow checking 
eliminates a vast array of problems. It's the #3 security bug of all time. dmd's 
source code does not use @safe, and I've recently noticed string handling code 
that had buffer overflow bugs in it as a result.

Nobody is going to guarantee the airplane you're flying on won't crash. But that 
doesn't mean all the efforts made to approach such a guarantee are pointless or 
doomed. The faults that result in an accident steadily get rarer and weirder.

Some have suggested that proofs could be constructed to prove @safe is correct 
in all cases. It's a good idea, but I have no idea how to construct such a 
proof, nor do I have any idea how to show that the proof itself covers every 
issue. The proof would inevitably be as complex as D itself is, putting this 
right back where we are now.

Criticism of @safe would be much more damning if using it caused unsafe 
behavior, but I am unaware of any such bugs.

Note also that the whole point of dip1000 is expanding the coverage of @safe.