On 8/23/18 8:03 AM, Walter Bright wrote:
On 8/23/2018 4:31 AM, Shachar Shemesh wrote:
This is in the language spec:
How many people know that without resorting to the specs.
This is a little unfair. It's plainly stated in the documentation for
foreach. Heck, I wrote a C compiler and the library for it, and
yesterday I had to look up again how strncmp worked. I refer to the
documentation regularly. Back when I designed digital circuits, I had a
well-worn TTL data book on my desk, too. If it wasn't documented, or
documented confusingly, it would be a fair point.
On the point of opApply, the choice is quite obvious. Why would you put
opApply in an aggregate if you didn't want to control foreach behavior?
Once you think about it, there shouldn't really be any more discussion.
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.
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.
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.
The forum can be anyone saying anything. A more reliable answer would be
the bugzilla entry being closed as "invalid", which did not happen.
There have been several people who I have spoken with in person, and
also seen posted here, that say the forum is unfriendly or not open to
criticism of D. I feel it's the opposite (in fact, most of the die-hard
supporters are very critical of D), but everyone has their own experiences.
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.
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.
-Steve
