On Thursday, 29 May 2014 at 12:45:20 UTC, Adam D. Ruppe wrote:
On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:
I dug into Chapter 3 about ranges. It clarifies a lot of
things about ranges.
Yeah, a lot of the stuff there comes from my own process when
writing my first range consuming function (which is still in a
pretty ugly form in my sha.d on github, I have never really
I have different types of range implementations throughout my
code now, which basically depicts the learning process while I
was trying to grasp the concept. I think the D website could do
with something like your Chapter 3. It's not really rocket
science, but when you have no guidelines, best practices
whatsoever, you have to experiment yourself which always leaves a
weird after taste, i.e. questions like "is this really the right
way? am I doing something wrong?".
I had to ask on the newsgroup: what does it really mean to
accept a generic input range? Does it mean to attempt data
transformations to receive anything? Or is it semi-strict? (the
answer is to take any input range but be strict on the element
type - don't try to transform it yourself as that introduces
bugs and hidden performance issues for the algorithm's user)
Yes, I always adhered to this rule.
I didn't quite understand the answer until some time later and
now I think it is fairly simple, but since I was so wrong about
it for such a long while I figured other people probably had
the same problems and tried to cover them in the book.
True, true. Your book was direly needed, and if it's just to
clarify things. Sometimes I would feel like a fool to ask
questions about ranges, thinking everybody understands them
except for me. Once you get the hang of it, it's pretty straight
One of the sections there talks about emulating random access
on a structure that doesn't really support it (a linked list)
and focuses on the hidden performance. That's the range-writer
side of the same range-consumer rule: don't try to get fancy
and support something the underlying data doesn't natively do
because then you'll introduce bugs and slowdowns that might be
hard to find.