On Mon, Mar 05, 2018 at 10:21:47PM -0500, Nick Sabalausky (Abscissa) via
> On 03/05/2018 12:38 PM, H. S. Teoh wrote:
> > This broke the by-value assumption inherent in much of Phobos code,
> Wait, seriously? Phobos frequently passes ranges by value? I sincerely
> hope that's only true for class-based ranges and forward-ranges (and
> more specifically, only forward ranges where copying the range and
> calling .save are designed to do the exact same thing). Otherwise,
> that's really, *REALLY* bad since non-forward ranges *by definition*
> cannot be duplicated.
I think you misunderstood. :-D Passing ranges by value means passing
the range itself, usually a struct, which is a value type. I did *not*
say the *content* of ranges are *copied* -- that would be so horribly
wrong that I would be thinking twice about using D for my projects. :-D
> The definition of "what is a forward/non-forward range" for
> struct-based ranges should have been "is this() @disabled (non-forward
> range), or is this() enabled *and* does the same thing as .save
> (forward range)?"
Yeah, Andrei has admitted before that this is probably what he would do
today, if he were given a second chance to design ranges. But at the
time, the landscape of D was rather different, and certain language
features didn't exist yet (sorry, can't recall exactly which off the top
of my head), so he settled with the compromise that we have today.
As they say, hindsight is always 20/20. But it wasn't so easy to
foresee the consequences at the time when the very concept of ranges was
still brand new.
What do you get if you drop a piano down a mineshaft? A flat minor.