Adam D. Ruppe's "D Cookbook" now available!

[Chris via Digitalmars-d-announce]

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 
> fixed it).

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 
forward.

> 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.