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.
